Testing Project: FAQ

Do we need to test the constructor?

Yes! Especially since the class's specification is ambiguous, you need the test cases to state what the code should do.

One of the constructors has package visibility, so I can't access it from my test class, which is in a different package. Should I change the constructor's access modifier? Or move my test class into the same package?

No! That constructor purposefully has package access. It's one way for you to see the limitations of JUnit testing.

Can I choose whatever specifications I want if the API is ambiguous?

Yes, within reason and it should make sense. (Something like "the car should start at Math.PI" doesn't make sense.) Also make sure that you're consistent in your specifications. If your constructor test enforces that a newly constructed Car is in park, then you shouldn't enforce that a newly constructed Car is in forward when you test your getGear method.

Wait, really? But, how can I create the specifications and find your faults? I don't know what your code does.

This is test-driven development: you are writing the tests that my code needs to pass. It's my code's job to pass your tests. However, you need to be consistent in your tests (you can't enforce something in one test method and then enforce the opposite in another), and the tests must be passable (e.g., you can't say in one statement that the expected output is 0 and then the expected is 1 in the next).

Should I test <some scenario>?

Probably, but try not to go down the exhaustive testing path, e.g., testing go(1), go(1.1), go(1.01). Try to be smart about what you're testing.

I feel like I'm going in circles. How can I test one method when it depends on the correctness of other methods?

Focus on the method that is under test; assume the other methods work. You have other tests that focus on those other methods and will reveal if there are problems in those methods.