[webbeans-dev] Granularity of assertions in TCK
by Pete Muir
Hi
Since the TCK audit has been rebuilt recently, we've lost a lot of the
granularity of the report. As we go through checking it we need to
make sure to reintroduce that granularity.
Here are a few guidelines (of course, sometimes they don't hold):
* A testcase should verify one thing
- in other words don't check two distinct thing in the same testcase
- it may well be the case that the spec asserts the same thing
multiple times (in different places), then it is fine to reuse the
testcase
- it may well be the case that a single check proves multiple
things (for example the fact that a bean resolves could be checking
type resolution rules, binding resolution rules etc.)
- use common sense - if a test seems to be checking > 1thing,
split it up
* An assertion should be fine grained
- if an assertion is being checked in multiple testcases (as
defined above), it's often an indication that the assertion isn't fine
grained enough
- sometimes multiple testcases are needed, but you should think
hard about whether you can split the assertion up (use tools like the
highlighter (_highlight_) and strikethrough(~strikethrough~) to split
the assertion up)
- if an assertion has something like "X and Y must through a
definition error if P, Q or R" then you should consider splitting this
into 2 * 3 = 6 assertions so that a test can be assigned to each one
if you need to split an assertions, takes it current ID and add an
extra letter on the end.
If you are wondering why these guidelines - simply that it makes
getting an overview of the TCK easily - we can scan through and check:
* how well covered a section is (whether or not it uses dense text to
define something)
* compare how dense a section is
* view easily how covered a section is
* easily check that a test is relevant to an assertion.
14 years, 9 months
[webbeans-dev] TCK test review
by Pete Muir
I've reviewed all the tests marked review and unknown apart from event
tests (for Dan to do). Some are still marked review - we should leave
those for now...
Pete
14 years, 9 months
[webbeans-dev] Testing non-contextual instances
by Pete Muir
Hi all,
Jozef and I just had a conversation about how to do this, and I
thought it was worth summarizing the discussion for everyone, as it's
not always obvious what the right approach is.
This is on the wiki http://www.seamframework.org/WebBeans/TestingNoncontextualInstances
Firstly, what are non-contextual instances?
Non-contextual instances are those objects which aren't managed by
299. For example, a Wicket component is managed by Wicket (it's
lifecycle is controlled by Wicket for rendering a page), or an MDB is
managed by the EJB container (instantiated or retrieved from the pool
for message delivery). In other words, they are never stored in 299
contexts.
However we still want to be able to apply 299 services to it (like
injection, callbacks etc.).
The spec defines the Java EE component classes to be non-contextual
instances; custom non-contextual instances may be defined, such as
Wicket components.
The Java EE component classes which are currently:
* Servlet - servlets, servlet filters, event listeners
* JSP tag handlers, tag library event listeners
* JSF scoped managed beans
* JAX-WS service endpoints, handlers
* EJB beans, interceptors
* Java EE platform main class (static)
* login callback handler
How do we go about testing these?
1) have the EE container to instantiate the object in whatever way it
normally would (e.g. servlet via web request, MDB via resource
adaptor, WS via WS call etc.)
2) if necessary cause a method to be called on the object (e.g.
deliver a message to the MDB)
3) check whether the required injection, callback etc. occurs (is the
value what we expect) in that method and set a flag showing that the
object is in the correct state. In general you can do this by
injecting an application scoped managed bean, and setting the flag on
that. This can then be got inside e.g. the test case and it's value
queried. Alternatively, if you are testing something that supports
returning some output (e.g. for http request the http status code
works well), you can use this to indicate the status to the test.
Any examples?
We have some similar tests - for example verifying the state of
contexts in servlet service methods. Take a look at
org.jboss.jsr299.tck.tests.context.application.ServiceMethodServlet,
and the corresponding test
org.jboss.jsr299.tck.tests.context.application.ApplicationContextTest
which uses the second pattern described above.
Often these tests are hard to write, as they require you to understand
not just 299, but other bits of Java EE, and how they inter-relate.
Ask in the IRC channel or here if you are stuck - likelihood is that
someone has experience of this area of EE.
14 years, 9 months
[webbeans-dev] Replacement pattern for Manager.getInstanceByType
by Clint Popetz
>From what I can tell, code that used to do:
manager.getInstanceByType(clazz)
now need to do:
manager.getReference(manager.getBeans(clazz).iterator().next(),clazz);
(plus checking that the set contains only one element and throwing an
exception if not.)
Is that really true? Is there no more direct way to obtain this in the
SPI? It seems like a pretty common case. If not, I can have a utility
method to do the above in the core, as many things don't cast to
ManagerImpl, so I'd rather not put it there.
-Clint
--
Clint Popetz
http://42lines.net
Scalable Web Application Development
14 years, 9 months
[webbeans-dev] TCK Tests Working Again
by David Allen
The TCK tests have been fixed to compensate for removal of deployment
types and other changes involving specialization of beans.
--
David Allen <drallendc(a)gmail.com>
14 years, 9 months
[webbeans-dev] Places WB needs "non-contextual" injection in JBoss AS
by Pete Muir
Hi Kabir, Jason,
As I mentioned, 299 requires that we inject any "Java EE components
classes supporting injection" with 299 dependencies:
* Servlet - servlets, servlet filters, event listeners
* JSP tag handlers, tag library event listeners
* JSF scoped managed beans
* JAX-WS service endpoints, handlers
* EJB beans, interceptors
* Java EE platform main class (static)
* login callback handler
Ales and I propose we do this via enabling 299 injection into MC
supported component models where possible.
Some (e.g. JSF) won't work, and will need other integration...
How far are all of these from being MC enabled?
How do we want to create JIRA issues for these to be done?
Note, I'm still missing the impl for this, but the API is something
like:
// for each class supporting injection
InjectionTarget it = beanManager.createInjectionTarget(type);
// for each instance requiring injection
it.inject(instance, beanManager.createCreationalContext(null));
// postconstruct hook
it.postConstruct(instance);
it.preDestroy(instance);
14 years, 9 months
[webbeans-dev] JIRA permissions update
by Pete Muir
Max and I discovered a way to change the permission scheme for a
project to correctly reflect the project. The main change you will see
is that:
* even if you are a member of the committers group, you no longer have
committer privileges on the project - if I forgot to add you to the
list of project committers, then please ping me
* the assignee list is now limited to the list of project committers :-)
This has been done for all WB projects.
14 years, 9 months
