Thanks for these guidelines Pete. I was feeling a bit confused about whether I should be stacking assertions on a test or not. Now I&#39;ve got a clear picture.<br><br>-Dan<br><br>Btw, they are now on the wiki: <a href="http://seamframework.org/WebBeans/JSR299TCK">http://seamframework.org/WebBeans/JSR299TCK</a> (feel free to reorganize)<br>
<br><div class="gmail_quote">On Wed, Jul 22, 2009 at 12:32 PM, Pete Muir <span dir="ltr">&lt;<a href="mailto:pmuir@redhat.com">pmuir@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi<br>
<br>
Since the TCK audit has been rebuilt recently, we&#39;ve lost a lot of the<br>
granularity of the report. As we go through checking it we need to<br>
make sure to reintroduce that granularity.<br>
<br>
Here are a few guidelines (of course, sometimes they don&#39;t hold):<br>
<br>
* A testcase should verify one thing<br>
    - in other words don&#39;t check two distinct thing in the same testcase<br>
    - it may well be the case that the spec asserts the same thing<br>
multiple times (in different places), then it is fine to reuse the<br>
testcase<br>
    - it may well be the case that a single check proves multiple<br>
things (for example the fact that a bean resolves could be checking<br>
type resolution rules, binding resolution rules etc.)<br>
    - use common sense - if a test seems to be checking &gt; 1thing,<br>
split it up<br>
<br>
* An assertion should be fine grained<br>
    - if an assertion is being checked in multiple testcases (as<br>
defined above), it&#39;s often an indication that the assertion isn&#39;t fine<br>
grained enough<br>
    - sometimes multiple testcases are needed, but you should think<br>
hard about whether you can split the assertion up (use tools like the<br>
highlighter (_highlight_) and strikethrough(~strikethrough~) to split<br>
the assertion up)<br>
    - if an assertion has something like &quot;X and Y must through a<br>
definition error if P, Q or R&quot; then you should consider splitting this<br>
into 2 * 3 = 6 assertions so that a test can be assigned to each one<br>
<br>
if you need to split an assertions, takes it current ID and add an<br>
extra letter on the end.<br>
<br>
If you are wondering why these guidelines - simply that it makes<br>
getting an overview of the TCK easily - we can scan through and check:<br>
<br>
* how well covered a section is (whether or not it uses dense text to<br>
define something)<br>
* compare how dense a section is<br>
* view easily how covered a section is<br>
* easily check that a test is relevant to an assertion.<br>
_______________________________________________<br>
webbeans-dev mailing list<br>
<a href="mailto:webbeans-dev@lists.jboss.org">webbeans-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/webbeans-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/webbeans-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br>
<a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br><a href="http://in.relation.to/Bloggers/Dan">http://in.relation.to/Bloggers/Dan</a><br>