Requirements and Design Proposal: AS7 TestSuite
by Andrew Lee Rubinger
Looks like a lot of us have different ideas for what the AS7 Integration
TestSuite should consist of, so I'll kickoff with what I believe is the
first design proposal towards getting coverage focused on the end-user
(not certifying our own internals).
I suspect this breaks down into two categories, which may be modelled as
separate modules under the existing "testsuite" aggregator parent:
* Specification
* AS-specific APIs
This isn't difficult work, though I do think it's important we consider
some hard rules. IMO we should be developing these suites as if we were
application developers, not wearing our server dev hats.
----------------
[End Goal]
1) No compile-time dependencies in the module except for what's
absolutely necessary.
For the spec suite, this means: JDK and EE Spec APIs only in the
compilation classpath. Testable asset sources and resources (ie. EJBs,
Servlets, etc) would live under src/main/* to enforce that. Only the
tests themselves would be located under "src/test/*".
The AS-specific API suite may also add in our own APIs to the
compilation classpath, but the line should end there. In "test" scope
we can place all runtime dependencies.
For the specification suite, AS-specific grammars like our own
deployment descriptors are fine; these are in many ways equivalent to
the TCK porting layer. We're not building a TCK; we're showing that our
implementation supports the features advertised.
2) Every single new test created is to have an associated JIRA.
We all remember the nightmare it was when the old AS4-6 suite would fall
down. We'd comb through each test, at times trying to determine its
purpose. By linking to JIRA we get history of intent, which acts as a
nice record even in the case that the test isn't so well-documented.
I'd argue that tests are a bigger asset than our code, and we should be
thinking about these in terms of long-term maintenance to outlive any
specific impl.
3) Documentation
Alongside the JIRA reference, a quick note about we're looking to
accomplish is something I find very helpful. I don't personally buy the
argument that code is self-documenting if written well. It gets
refactored and stale over time.
4) Run-mode profiles
Arquillian provides a wonderful abstraction such that we can get
coverage for AS in both remote managed *and* embedded modes without
changing the test itself. To certify that everything is working as
advertised no matter the runtime, we should be able to run the same
suite in standalone, domain, and embedded modes (generally speaking).
5) Porting of AS6 Tests
There's no discounting the value this coverage has given us, though I
question the purpose of a lot of these tests. I think a great majority
of these need to come into the new codebase, refactored to align if needed.
----------------
[Current State]
Here[1] is an example of what I believe to be a simple, well-written
test, with the exception that the tested Servlet and EJB are in the same
test source folder.
The current "testsuite" aggregator contains modules which mix our
end-user certification stuff alongside internals, so I think these
should be separated out.
A lot of this is set up in some fashion already, but I would like to see us:
1) Agree upon a strict scope for each type of testsuite along the lines
of my points above, once we reach agreement
2) Upgrade to ARQ 1.0.0.Alpha5 (which implies ShrinkWrap
1.0.0-alpha-12), just released tonight. Currently AS is on a forked
release of ARQ for OSGi purposes, and these changes, if necessary, need
to get upstream so we can do upgrades.
It's clear that AS7 has made full-steam-ahead progress since last
summer, and with a little organization our testsuite can give us a great
view of where we stand, from an end-user's perspective, with minimal
investment.
S,
ALR
[1]
https://github.com/jbossas/jboss-as/blob/master/testsuite/integration/src...
13 years
IMPORTANT New JIRA Policy & Massive JBAS JIRA Reorg/Cleanup
by Jason T. Greene
Hi Everyone,
I'm sure many of you will agree that the JBAS jira has had a very poor
signal to noise ratio for awhile now. his has been a problem since
important issues often go unnoticed, and it's extremely time consuming
to do any kind of release or organization.
Our release model is such that we only focus on one major release at a
time. Once that happens it typically becomes part of the enterprise
product line which has it's own JIRA project (JBPAPP). Since we have a
very new architecture with 7, there isn't much value in keeping around
hundreds of stale issues which may not be relevant any more.
So, I have /closed all issues that were not assigned to an as7 release/
as out of date.
I have also renamed all components that are no longer relevant to be
prefixed with z - Legacy (to sort at the bottom).
From now on JIRA should accurately reflect our 7 timeline and work queue.
I am asking for everyone's help though in keeping this manageable by
doing the following:
1. When creating an issue that you intend to assign to yourself, pick a
fix-for release version that you can commit to achieving. Please be
realistic in making this choice, as very few of our issues do not get
rescheduled.
2. If you can not commit to a point in the schedule, but you just want
to log the issue to be worked on, then leave it unassigned and set the
fix-for to be "Open to Community". I am hoping this will be an easy
place to point people that want to jump in.
3. If you have an issue you know you cant work on, but think it is
timeline sensitive, then leave it unassigned and let me know about it.
We will figure out a way to resource it.
4. If you validate that a bug is valid then please schedule it or leave
a note so that when I go through them I can find a place for it.
5. If you are a component lead you will probably get auto-assigned. The
intention is that you will either take on the issue, delegate it to
someone else, verify it and unassign, or in the worst case just unassign.
Also note that I may close issues that are continually not resolved when
scheduled, so if you really care about the issue please schedule it
reliably.
If we do this right, we should start to see that each release has a
manageable number of issues on it, and that everyone has a reasonable
number assigned to them.
If you have any questions or any other ideas on how we can get a more
accurate reflection of our work in JIRA, then let me know.
Thanks!
--
Jason T. Greene
JBoss, a division of Red Hat
13 years
update-resource-operation?
by Heiko Braun
I am wondering if we support update operations already?
I can only see add and remove.
Ike
13 years
Distribution of testing modules
by David M. Lloyd
In our current modules distribution for AS7 we currently are distributing:
- JUnit
- HTMLUnit
- JSFUnit
- Arquillian SureFire
- the AS7 Arquillian subsystem
- ShrinkWrap
- Various glue and support modules for the above
- Probably more test-oriented stuff I missed in my glance-over
The question is:
1. Do we really want to be distributing these test frameworks?
2. If so, should we put them in their own area somehow?
3. Also if so, should be recommend, as a policy, how and when these
modules should be used by end users?
4. If not, how can we exclude them from the final build?
--
- DML
13 years
Arquillian and JPDA on AS7
by Anil Saldhana
Hi all,
I have a test case that constructs a web archive using arquilian and
then deploys on AS7.
But I am not seeing any way to use JPDA on AS7 via the JUnit test
because Arquilian is starting the container. Neither the standalone.conf
JPDA settings nor the vm arguments set in eclipse allow me to trace
through AS7 code.
Anybody else faced this?
Regards,
Anil
13 years
What is AS 7 kernel ?
by developer251＠libero.it
Dear JBoss developers,
I'm interested to learn more about the release 7 of the application server.
The most basic question is: does JBoss 7 has a completely new kernel
architecture ?
I cannot see traces of Microcontainer in logs, rather :
14:59:45,906 INFO [org.jboss.modules] JBoss Modules version 1.0.0.Beta16
14:59:47,375 INFO [org.jboss.msc] JBoss MSC version 1.0.0.Beta7
Is there any thread/link which discusses a bit about this ?
thanks a lot
Paul
13 years
AS7 Arquillian and OSGi
by Andrew Lee Rubinger
I'm looking to upgrade ARQ in AS:
https://issues.jboss.org/browse/JBAS-8946
...but AS is using a fork of Arquillian:
<version.org.jboss.arquillian>1.0.0.Alpha4.SP9</version.org.jboss.arquillian>
First, I can't find the source location for this tag. Closest I can see is:
https://github.com/tdiesler/arquillian/commits/1.0.0.Alpha4.SP7
...and also there's some ARQ branch:
https://github.com/arquillian/arquillian/commits/1.0.0.Alpha4-OSGi
It's possible/probable that I missed some discussion on the reasoning
behind this, but I want to put a stop to this kind of forking. Yes, I
know that AS needed a release of ARQ before ARQ was ready for alpha-5.
AS is in a position to fuel Arquillian development, and at the very
least if forks are needed in a clutch, they've got to go into the
authoritative Arquillian repository:
https://github.com/arquillian/arquillian
That said, I'm looking to resolve this and bring any changes that are
demanded by AS back in line with current ARQ upstream/master.
If you can point me at where the SP9 tag lives, I can start a discussion
w/ Aslak about what we need to do to bring these changes into
upstream/master. Perhaps some additional layering will be necessary to
tack on OSGi-specific stuff that shouldn't be in ARQ core, and we should
handle that too.
But long-term, AS is going to need a version of ARQ that's not forked
off current development so that we can do drop-in-place upgrades.
S,
ALR
13 years
Bug or Feature: JVM not set on server-config
by Heiko Braun
[localhost:9999 /] /host=local/server-config=server-three:read-resource
{
"outcome" => "success",
"result" => {
"path" => undefined,
"system-property" => undefined,
"interface" => undefined,
"jvm" => undefined,
"name" => "server-three",
"group" => "other-server-group",
"socket-binding-group" => "standard-sockets",
"socket-binding-port-offset" => 250,
"auto-start" => false
},
"compensating-operation" => undefined
}
13 years
