Test-driven development is an iterative process. You write a simple test, and that forces you to write an implementation that passes the test. Then you see that the implementation is incomplete, but rather than immediately modifying the implementation, you first modify the test to force the implementation to be complete. You are being your own adversary in a sort of a game. The implementation is designed to be as simple as possible to pass the test, and the test is designed to force the implementation to be completely correct. The main benefit of this process is that it results in a set of tests that fully capture the specification. In other words, the goal is that the tests are so thorough that any implementation that passes the tests should be considered correct. Also, it's fun to develop software this way.
In Studio 8, you develop an implementation of the IntList interface in the form of a Doubly Linked List. The test included with that studio was monolithic: the test could be run only after a significant portion of the implementation was complete.
For the bridge, you are tasked with writing a sequence of JUnit test cases, with the goal of facilitiating test-driven development of Studio 8. You must think about how you would stage the various development of the methods within DoublyLinkedListOfInts.
This does not necessarily mean that a given test is written to test just one specific method. Instead, think about how to stage development so that small steps can be taken in the implementation of all of the methods. Sometimes this will mean a bit of work in several methods; sometimes this will mean a bit more work in just one or two methods.For example, an early test should verify that an empty list performs correctly. The appropriate result would be returned by size, indexOf, etc.