Executable Test Files

You may have years of experience in organizing programming code; certainly someone on the team will. Organizing the tests will be pretty much the same sort of thing. It boils down to dividing up the tests into individual files. Some of how you do that will be driven by the language in which you write the tests. For instance, in Java, each class must be in a separate file whose name is the name of the class, so if you have a test named LoginStoryTest, it's just going to go into a file named LoginStoryTest.java as simple as that.

We omitted some of the Java declarations and directives from our examples in the previous chapter, because we were focusing on the tests themselves. The stuff we omitted is the same every time (except for names), so it doesn't require any brainpower. This stuff actually organizes the tests, though, so we're going to look at it now.

Our example test of the login function is actually a Java class. Don't let this terminology scare you if you're not a Java programmer. A class (for our purposes) is just a blueprint for something in this case, for our test. Here's some of the stuff we omitted:

 public class LoginStoryTest {     public void testLogin() {   // This is where the tests were    } } 

These declarations say this is the class (blueprint) for a LoginStoryTest and that a LoginStoryTest has a method (something it can do) named testLogin.

Our tests are in the testLogin method because (you guessed it!) they test the login. The login function is part of the login story, so it all goes into the TestLoginStory class, in a file named TestLoginStory.java. Pretty simple, eh? Well, logging in is pretty simple. Let's look at the exercise from the last chapter, which you should have studiously completed before reading ahead to this point. The story involved is, in part: User can create, update, display … a task.

We only asked you write an executable test for the create portion, but you can see that you'd also need to write tests for update and display. Here's how that would be organized:

 public class TaskStoryTest {     public void testCreate() {   // Create tests go here    }    public void testUpdate() {   // Update tests go here    }    public void testDisplay() {   // Display tests go here    } } 

The tests for each major function within the story go into an appropriately named method. This keeps the number files associated with the tests manageable (one for each story) and puts closely related tests within easy reach of each other. One of the extremely useful features of the XUnit family of test frameworks is that no matter how many of these test methods we put into TaskStoryTest, the test runner will find and execute them all.