"ALRubinger" wrote : "pgmjsd" wrote : * I'm not sure about the "package per jira issue" convention. But hey... if that's how you wanna roll. | | This is something we'd adopted with some success in EJB3. Basically the JIRA-issue namespace allows us to be very clear about which classes are used in which tests. For shared/common stuff, the ".jbbootXX" package isn't necessary, but in some cases its convenient to show the isolation. I'm not going to enforce any hard-and-fast rules here. So long as everything is tested in readable/obvious form, do what makes most sense to you. The rules which apply and should be enforced are: 1. each test must clear state which function it's testing We have a lot of tests which do some form of setup do get to the actual state in which a function can be tested. If a test doesn't clearly define its goal, then regression might happen because an unrelated function (which is used) is refactored. 2. each test is a guard against (backwards compatibility) regression You not change a test because it's failing. That would break backwards compatibility by default. You should only change those bits of a test that are affected by a bug fix. The two are very much intertwined, but as a rule the Jira issue stipulates the test goal and keeps track of which version is affected. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238998#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...