Comments on: Reorganizing long test classes http://alexruiz.developerblogs.com/?p=366 Having Fun with Java! Thu, 19 Aug 2010 17:21:54 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Alex Ruiz's Blog » FEST-Swing 1.2a3: GUI Testing Made Easy http://alexruiz.developerblogs.com/?p=366&cpage=1#comment-3220 Alex Ruiz's Blog » FEST-Swing 1.2a3: GUI Testing Made Easy Tue, 01 Sep 2009 15:20:12 +0000 http://alexruiz.developerblogs.com/?p=366#comment-3220 [...] a good number of bug fixes, new features and improvements. We also improved our test suite: we reorganized our tests and the test suite grew from 2,677 to 3,405 tests! (with 100% success rate, of [...] [...] a good number of bug fixes, new features and improvements. We also improved our test suite: we reorganized our tests and the test suite grew from 2,677 to 3,405 tests! (with 100% success rate, of [...]

]]> By: Alex Ruiz http://alexruiz.developerblogs.com/?p=366&cpage=1#comment-1184 Alex Ruiz Mon, 10 Aug 2009 21:00:10 +0000 http://alexruiz.developerblogs.com/?p=366#comment-1184 <a href="#comment-922" rel="nofollow">@Konstantin Scheglov </a> Well, I don't feel guilty at all :) I'm using underscores for naming test methods only, any other code uses the regular Java code conventions. In my case, I found that underscores really make it easier to read test code. At the same time, the team has to agree about using underscores for method naming or any other practice that is not considered "standard." So far, nobody in the FEST team has complained ;) Cheers, -Alex @Konstantin Scheglov

Well, I don’t feel guilty at all :)

I’m using underscores for naming test methods only, any other code uses the regular Java code conventions. In my case, I found that underscores really make it easier to read test code.

At the same time, the team has to agree about using underscores for method naming or any other practice that is not considered “standard.” So far, nobody in the FEST team has complained ;)

Cheers,
-Alex

]]> By: Konstantin Scheglov http://alexruiz.developerblogs.com/?p=366&cpage=1#comment-922 Konstantin Scheglov Sat, 08 Aug 2009 19:12:44 +0000 http://alexruiz.developerblogs.com/?p=366#comment-922 One my colleague hates me because I use same naming scheme as you do - use underscores. I do this long time, probably 2-3 years and all this time he asks me to stop using it. He says that it is hard to read and it violates Sun Java code conventions. What do you think about this? Do you feel yourself guilty because you violate standards? One my colleague hates me because I use same naming scheme as you do – use underscores. I do this long time, probably 2-3 years and all this time he asks me to stop using it. He says that it is hard to read and it violates Sun Java code conventions.

What do you think about this? Do you feel yourself guilty because you violate standards?

]]> By: Alex Ruiz http://alexruiz.developerblogs.com/?p=366&cpage=1#comment-171 Alex Ruiz Wed, 29 Jul 2009 18:46:56 +0000 http://alexruiz.developerblogs.com/?p=366#comment-171 <a href="#comment-162" rel="nofollow">@Giorgio Sironi </a> I agree. That is something that I've been thinking about too. <code>JTreeDriver</code> is doing to much. I have plans to divide it several classes as "gestures", "assertions" and "queries". That is a huge change in the code base, but necessary. This changes will be internal though, the public API won't be affected :) Thanks! @Giorgio Sironi

I agree. That is something that I’ve been thinking about too. JTreeDriver is doing to much. I have plans to divide it several classes as “gestures”, “assertions” and “queries”. That is a huge change in the code base, but necessary. This changes will be internal though, the public API won’t be affected :)

Thanks!

]]> By: Giorgio Sironi http://alexruiz.developerblogs.com/?p=366&cpage=1#comment-162 Giorgio Sironi Wed, 29 Jul 2009 09:40:34 +0000 http://alexruiz.developerblogs.com/?p=366#comment-162 You can also divide the test methods by scenario; the common setUp and tearDown is probably a sign of a common scenario, the "given" part of a test. Beware that a very long test case class can be a smell of a violation of Single Responsibility Principle by your system under test: often if you're writing 40 test methods the class is doing too much, and you could factor out a collaborator that will handle the functionality which is less cohesive with the rest of your SUT. You can also divide the test methods by scenario; the common setUp and tearDown is probably a sign of a common scenario, the “given” part of a test. Beware that a very long test case class can be a smell of a violation of Single Responsibility Principle by your system under test: often if you’re writing 40 test methods the class is doing too much, and you could factor out a collaborator that will handle the functionality which is less cohesive with the rest of your SUT.

]]> By: Alex Ruiz http://alexruiz.developerblogs.com/?p=366&cpage=1#comment-156 Alex Ruiz Tue, 28 Jul 2009 16:30:58 +0000 http://alexruiz.developerblogs.com/?p=366#comment-156 <a href="#comment-155" rel="nofollow">@Michael Hüttermann </a> Hey my friend! As I mentioned in our conversation on Twitter, so far I'm pleased with the results. It is very easy to find tests for a specific methods. Test classes are small and very focused. I also found that in some cases, one test-class per method-to-test is an overkill. I'd like to kindly ask you to review the code before I check-in. I'm sure we can find a good balance! :) @Michael Hüttermann

Hey my friend!

As I mentioned in our conversation on Twitter, so far I’m pleased with the results. It is very easy to find tests for a specific methods. Test classes are small and very focused. I also found that in some cases, one test-class per method-to-test is an overkill.

I’d like to kindly ask you to review the code before I check-in. I’m sure we can find a good balance! :)

]]> By: Michael Hüttermann http://alexruiz.developerblogs.com/?p=366&cpage=1#comment-155 Michael Hüttermann Tue, 28 Jul 2009 16:15:38 +0000 http://alexruiz.developerblogs.com/?p=366#comment-155 One test class per method results in a huge test class base. I prefer adding a couple of test methods in a test class with the restriction that they should all share the same setUp/tearDown. This leads to a more focussed test base. Of course this may also result in longer test classes .. if the length of test classes is important, you may use Checkstyle to monitor your expectations. But also here it is helpful to first define your expectations and then validate them (continuously). Me personally, I can work with longer classes, for me it is more critical how complex they are (e.g. McCabe). Longer ascii files can be managed by all IDEs, but only scoped ones are easy to maintain and to extend by the man in front of the desk (Cohesion vs Coupling are magic words here). One test class per method results in a huge test class base. I prefer adding a couple of test methods in a test class with the restriction that they should all share the same setUp/tearDown. This leads to a more focussed test base. Of course this may also result in longer test classes .. if the length of test classes is important, you may use Checkstyle to monitor your expectations. But also here it is helpful to first define your expectations and then validate them (continuously). Me personally, I can work with longer classes, for me it is more critical how complex they are (e.g. McCabe). Longer ascii files can be managed by all IDEs, but only scoped ones are easy to maintain and to extend by the man in front of the desk (Cohesion vs Coupling are magic words here).

]]> By: Hamlet D'Arcy http://alexruiz.developerblogs.com/?p=366&cpage=1#comment-153 Hamlet D'Arcy Tue, 28 Jul 2009 15:55:05 +0000 http://alexruiz.developerblogs.com/?p=366#comment-153 The other alternative is creating one TestCase per common setup/teardown. The results in a highly cohesive test... all the test methods use all the fields in the class. Your approach seems good when there aren't a lot of cross-method dependencies (doFoo() depends on doBar()) but a shared fixture approach might be better there are more cross-method dependencies. AND... cross method dependencies is probably a code smell for temporal coupling or some such. The other alternative is creating one TestCase per common setup/teardown. The results in a highly cohesive test… all the test methods use all the fields in the class. Your approach seems good when there aren’t a lot of cross-method dependencies (doFoo() depends on doBar()) but a shared fixture approach might be better there are more cross-method dependencies. AND… cross method dependencies is probably a code smell for temporal coupling or some such.

]]>