Testing code in Java that is only loosely defined

Question

My question is about testing in general. At school, professors say that testing has to be written before we begin to write some code. I guess we need to use EasyMock to represent the classes not written yet. But I think something is wrong in my understanding of that concept.

How can you write testing code when nothing has been defined except interfaces?

And if you do it, when do you run the tests? Once you've defined the classes and you've written the code, EasyMock has no place; you can use JUnit for testing.

Answer 1

This is the driving motivation behind Test-driven development, with the principles being thus:

• You do not write code without tests.
• You write just enough code for the test to pass.
• You refactor the code that you have written and ensure that tests pass.

I think I understand what you're getting at - you don't know if you can/should write tests for objects you haven't defined yet. If you're following TDD, you should at least define the class, and once you've done that, you can start writing tests.

Interfaces are nicer since you don't have to care about what concrete object is implementing it, so long as the tests pass. Then you'd declare the interface and a class that implements it, but nothing more.

The main guiding principle is that you are always running tests. Every time you change that single unit of code you run the test against it to ensure that breakage hasn't occurred. When you're done, you run the suite.

To that point, EasyMock is only a mocking framework - it's meant to pretend that an instance of a defined class exists. There's a time and place for mocks, and this is not one of them; you're not going to gain anything by mocking out a class that has no definitions.

Answer 2

The idea behind test-driven development is that your tests are written in the form of scripts, running through the flow that a user or client package would take if they made use of the software you are about to write.

Obviously at first your test classes will be full of errors which complain that the classes and methods don't exist (or they do exist but simply throw an exception which says that the method has not yet been implemented). But, once your test script outlines the scope and expected behaviour of these embryonic methods, the next step is to write code for all of those classes and methods, and keep running your test scripts until every test passes.

Alongside these flow scripts, you need to have unit tests which attack every method with every type of valid and illegal parameter. Tests should exist to make sure that null parameters, empty/zero parameters, and parameters of the wrong form are handled appropriately, either by throwing an exception in the case of invalid data or returning the result expected in the case of valid data.

Even if you set out to write all tests before writing any actual application code, you'll probably find that you end up writing new application code before writing tests for it, at least some of the time.