Lab Exercise: Test Driven Design

As you program larger, more complex, projects it is vitally important that you have confidence that the most basic aspects of your code works correctly by automatically testing it. Unit testing of individual methods is the most common technique used across all languages and built into all major IDEs. It has even been important in changing developers' habits — by practicing test-driven development (TDD) they produce tests along with their code features instead of waiting until the code is complete. Besides helping to structure your programming time, it provides a host of other benefits and even more!

This is the third eXtreme Programming practice you have seen that has become well established in industry because, when combined, they actually improve program design and help make teams more successful:

• Refactoring: improving code's design in controlled iterative steps — that can be done with confidence when backed by existing tests that can be run automatically before and after each change
• Pair Programming: working actively with another programmer on a single computer — that allows for constant code review and knowledge sharing to produce the best draft of code before committing it
• Test Driven Design, TDD: writing automated tests for the code before writing the code itself — that encourages you to consider the code's design (its interface) by figuring out how to test it

Submission

At the end of lab, use Gitlab's Merge Request to submit your code to the original organization repository. Make sure your NetID is in the title of your Merge Request: lab_testing - participating NETIDs

Resources

• TDD with IntelliJ

Specifications

In your OOLALA team, use a forked version of the lab_tdd project, in the package tdd, to solve the following problem from scratch using TDD to try to establish a coding rhythm:

A parking garage provides a fixed number of parking spaces for vehicles and must maintain information about the vehicles that are currently in the parking garage so it can report the number of spaces available and the current value. A parking garage must provide publicly available functions to be called when a vehicle enters the garage and when a vehicle leaves the garage that throw exceptions if there is not enough available space in the garage, if a vehicle tries to enter that is already in the garage or if a car that is not in the garage tries to exit. Additionally, the garage must provide publicly available functions that report the total capacity of the garage, the number of available spaces in the garage, and the total money collected. The parking fee is assessed when a vehicle enters the parking garage.

Currently, there are three distinct types of vehicles: cars, low-emission cars, and cargo trucks. Every vehicle has a license number consisting of letters and/or numbers and the number of parking spaces it occupies. Cars have a passenger capacity (i.e., the number of passengers). Trucks have a gross vehicle weight it can transport. Cars take up one space, while trucks take up a number of spaces that is their gross weight divided by 10,000. Cars are charged a rate of $8, low-emission cars are charged half that rate, and trucks are charged $10 per 10,000 pounds of gross weight.

Start by writing a test (in a separate well named method that shows the intention of the test, annotated with @Test, with its own call to the appropriate JUnit assert statement or test for a thrown Exception), then write the most simple code to make that test pass (i.e., do not write a complex data structure until you need it). In order to see the process more clearly when working as a group, one person should write the test and let another person write the code to pass that test as well as the next test, then another person fixes that test and writes the next test and so on.

To show you are actually following the TDD process, you should have a lot of GIT commits (where the first one represents a test that fails and the next one represents code that causes that test to pass). Obviously that is not how you would typically commit your code to the repository but this is just to establish that you are doing the work in the correct order.

Note, you will not need to write a Main class or main() method or interact with the user for this exercise since the tests should fully exercise the code.

If you are having trouble thinking of how to come up with appropriate tests to follow this process, this TDD challenge shows a series of tests in the order you might write them for a different application (and in an older version of JUnit).