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. Also, what does this organization (tests in a separate package) make the tests focus on?

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 hardcode the gears (e.g., 0, 1, or 2) in my code or should I use the Car class's constants?

Use the constants. If the Car class changes the constants, e.g., REVERSE is now -1, you don't want your tests to not work anymore. (DRY principle)

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.

Should all of my test classes compile?

Yes.

I am getting a deprecated warning when I use assertEquals when passing in two doubles.

deprecated means that that method will no longer be supported in future versions of the API. You should use the supported method, which takes a delta (an error tolerance) as a parameter. See the example tests.

Can I change the Car class?

You can change the Car class, but your tests should not change the API (additions or removals). Your tests need to work with my code, which has the given API.