10

I am working on a web application with an existing code base that has probably been around for 10 years, there are ~1000 class files and ~100,000 lines of code. The good news is that the code is organized well, business logic is separate from the controller domain, and there is a high level of reusability. The bad news is there is only the very beginnings of a test suite (JUnit); there's maybe 12 dozen tests at most.

The code is organized fairly typically for an enterprise Java project. There is a stuts-esque controller package, the model consists of almost purely data objects, there is a hibernate like database layer that is largely encapsulated within data access objects, and a handful of service packages that are simple, self contained, and logical. The end goal of building this test suite is to move towards a continuous integration development process.

  • How would you go about building a test suite for such an application?
  • What tools would you use to make the process simpler?

Any suggestions welcome. thanks!

Peter Anthony
  • 487
  • 4
  • 11

4 Answers4

7

Start by reading Working Effectively with Legacy Code (short version here). Next I would write a couple of end-to-end smoke tests to cover the most common use cases. Here are some ideas on how to approach it: http://simpleprogrammer.com/getting-up-to-bat-series/

Then when I need to change some part of the system, I would cover it with focused unit tests (refer to the aforementioned book) and then do the change. Little by little the system - or at least the parts which change the most often - would be better covered and working with it would become easier.

Esko Luontola
  • 73,184
  • 17
  • 117
  • 128
3

I would create a few integration tests. Since they toch a lot of code, you probably will get an error when you screw up bigtime.

I wouldn't 'build a testsuite' as such, but rather before changing some part define a testset for it, and then go about changing it.

I would suggest looking into a test coverage tool (I don't code Java, so no clue what tool the best is for Java). While it does not tell you when you've tested enough, it does tell you when you tested too little ;)

Good luck!

markijbema
  • 3,985
  • 20
  • 32
2

If the project isn't already maven-ized I would do that. Also be sure to use a mocking framework like mockito. Hudson is a nice CI tool that integrates nicely with maven.

Kevin
  • 24,871
  • 19
  • 102
  • 158
  • The project already uses ant extensively, though the builds are fairly simple, so I could see migrating to Maven for a compelling reason. – Peter Anthony Jul 15 '11 at 22:32
  • I'm sure Hudson integrates with ant as well. Here's a comparison of ant vs. maven: http://en.wikipedia.org/wiki/Apache_Maven#Maven_compared_with_Ant. One reason I like maven specifically with regard to testing is you can just drop a java file under the project's src/test/java/ and it gets run at the test phase of the build. – Kevin Jul 15 '11 at 22:38
1

It looks like you are going to be writing both unit and functional tests, so JUnit might not be the best fit for this. Have you considered TestNG? Since you only have very few tests right now, you have the option to pick what's best for the job.

Cedric Beust
  • 15,480
  • 2
  • 55
  • 55
  • thanks! I neglected to mention that we do have a handful of functional tests using selenium, via the browser. why do you prefer TestNG to JUnit? – Peter Anthony Jul 19 '11 at 18:56