This article, the first in a four part series on test-driven development (TDD), introduces TDD and provides references to tools that are useful for TDD. Upcoming topics covered in this series include unit testing of EJB components and POJO classes, black box and in-container testing of servlets and JSPs, and in-container testing of Struts web applications.

Read Test-Driven Development Series Part 1 - Overview

jWebUnit is mentioned as a "macro library for HttpUnit". Another similar tool that also sits on top of HttpUnit is WebTest (http://webtest.canoo.com).

The difference is that in WebTest the test steps are defined in XML and are executed in custom ANT targets. I found it quite pleasant to use.

... it's about design. The article just talks about how good testing is (which it is) and the benefits of having lots of tests that can be automated (which are great).

The real benefit of TDD is the design process. With TDD and refactoring, a design can emerge in a positive direction as the test cases are first class users of the code. This requires the code that is under development to be well constructed and modular to allow for this to happen, and not the "standard" unit testing of "set up the container, run some end-to-end tests and pat yourself on the back".

For some really good quality books and articles on TDD have a look at these:

Dan North's article (and also covered by TSS)
http://www.sys-con.com/story/?storyid=37795&DE=1

Ken Beck's book _Test Driven Development: By Example_

and my favourite
Robert C. "UncleBob" Martin's _Agile Software Development, Principles, Patterns, and Practices_.

Please don't think about TDD as testing, because if you do, you're missing the point.

Agreed! This article completely misses the point of TDD. It should be re-named to "Automated Testing" or similar.
TDD is about design, the tests are just a side effect.

Read Dan North's article!

StrutsTestCase also allows for testing with mock objects and it works great. No need to start/stop servers, no nothing, just run these tests along with all your other junit tests without hassle or loss of time. With mock objects and refactoring, what are the rare cases where in-container testing of server-side code is still needed?

This article should really be renamed to Unit Testing Tools, or Automated Testing, or even Regression Testing.

Very poor introduction to TDD. Doesn't explain the evolution of TDD, but just goes right into the tools.

I have used BPEL ( http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/ ) to build a test framework that I am using for my current project. Although BPEL is meant for business process orchestration, it's working out nicely as a test framework. Variable and Assign semantics in BPEL allowed me to do functional testing of complex statefull use cases. The only downside was that I had to expose as web services whatever server side functions I wanted to test .

Pranab

It allows you to programmatically recreate the way the user walks through an application. It is aimed at web applications. Disadvantage is that you do have to specify form fields and values for testing of posting of forms. But you can let the script do things like log in to a site and work with conditions and branches. It also allows for load testing.

http://jakarta.apache.org/jmeter/

Marc

The article starts with TDD, only then to deviate to talk about automated testing. TDD is all about "Test Perspective" right from the design phase. As some one has said earlier, may be worth removing TDD from the title.

Seems strange that StrutsTestCase is included in the tools section. While it is a great tool for testing Struts mappings (and in my opinion that's all it should be testing) is it not a bit too specific? You would think that Cactus, MockObjects, and or EasyMock (as well as the extention that allows mocking of classes - for example see http://blogs.codehaus.org/people/vmassol/archives/000250_mocking_classes_with_easymock.html) would be more appropriate in an article that aims to cover TDD in general. Not including mocking in the overview and at least one tool would place a huge obsticle in front of someone who was trying to unit test code in isolation. In the case of Struts your action tests would become acceptance tests, which does not need to be the case if they are tested as independent units, and adds unnecessary complexity to your test.

I agree that test-driven development is more than suggested in this article. You start with a test that fails, make it work, etc. This makes me curious how other development teams combine this with EJB development. Using Cactus takes a lot of time (compiling and deploying to app server can take several minutes). TDD requires that you can update your code and run your tests very quickly.

Using mock objects could work, but can also be difficult when using transaction and other container related features (e.g. queues). What we are looking for is hot-deployment of a single EJB instead of a complete application. Ideas?

Stephan

What app server are you using?

This has worked for me on JBoss and OC4J. In a directory named test have a seperate build.xml and configuration files for building a test EAR file. The build.xml grabs IDE compiled code (saving time) and 1) puts it all together 2) copies the file to the server. Total time running the build.xml should not be more than a several seconds, depending on how many jars are needed to support the EJB, and provided that the build.xml does not need to compile and can just grab classes. If things still take too long then something can always be decoupled and mocked (chosen in order of greatest complexity first).

Mostly though, I stay away from EJBs because I don't have distributed transactions.

Ahah!

This is exactly what Jon and others are talking about - TDD is about design. If it is hard or time consuming for you to test in-container then design your code to minimise the amount of in-container testing you have to do..

write your EJBs to delegate business functionality to POJOs ( plain old java objects) so that the EJB itself is just a shell that provides an execution context. Then exhaustively test the POJOs with fast out-of-container tests.
Now all you need is one in-container integration test to make sure eveything hangs together.

But what if the POJOs need to use services like queues etc? Then mock them
for your POJO tests. But those are complex interfaces and hard to mock? then dont mock them. Have the POJO itself delegate message sending to a MessageSender class that know how to talk JMS and has a much simpler interface itself. Then mock *this* class when testing your POJO to check the POJO uses MessageSender correctly. Now all you need is a quick test of the real MessageSender to check it really knows how to talk JMS.

oh and look, almost by accident, if we ever want to change the app to talk something other than JMS we have a design that facilitates an easy change by swapping in a new version of MessageSender.....

Yes, out-of-container testing is essential, where unit testing is concerned. You can't usually get equal code coverage testing in the container--although of course you need to perform integration tests as well.

This is exactly what Jon and others are talking about - TDD is about design. If it is hard or time consuming for you to test in-container then design your code to minimise the amount of in-container testing you have to do..
Spring is designed to facilitate this. For example, you never need to use JNDI directly, even if you use EJB: you just get to work with the business methods interfaces of your EJBs directly: the container provides the reference with no lookup required. Practising TDD is easy.

As Perryn points out, if you have an abstraction interface that doesn't depend on the container, mocking is easy and reuse is easy in different contexts.

Check out www.mockejb.com ...

That should have been www.mockejb.org ... Sorry for confusion,

Ilya.

The article's introduction brings to the attention of the reader a concept called test-driven development and calls it "new". How was the rest of the article? Don't know. I would not waste my time reading an article by anybody that ignorant. Go back and read Mythical Man-Month and 10,000 other books that covered the topic in the last century.