ScentsOfTestsFindingYourFragrance

From SPA Wiki

In this workshop the participants looked at a number of code listings grouped as pairs of alternative approaches to implement a certain test or tests. The following is a record of observations collected during the debriefing of this exercise.

Contents 1 Testing for Interaction vs. Testing State 2 Choosing between JDave and JUnit 3 To DSL or not, that is the question 4 Monolithic scenario vs. nitty-gritty detail tests 5 Easyb vs. JUnit 6 Mock vs. fake

Testing for Interaction vs. Testing State

• If you test objects' state, are you also testing the collaborator?
• If you mock collaborators, are you locking down the object's behavior in too much detail?
• If you mock the collaborator, you can postpone its implementation for later.
• Whether both the object-under-test and the collaborator are in your control might influence your decision.

Choosing between JDave and JUnit

• Do you know the tool in question?
• JDave has a lot of boilerplate due to it being Java.
• JDave helps if you're sensitive to words like "test".
• Do you like Hamcrest assertions? Both support them, both work without them.
• "DSL" style (fluent) assertions in JDave are more explicit than traditional assertions.
• JDave helps in making multiple contexts/fixtures explicit.

To DSL or not, that is the question

• Should you test DSL be(come) part of your production code/API?
• The implemention of a DSL adds mutable state and complexity to your code base.
• DSL's are good for making builders.
• DSL's are good for reducing duplication when you have lots of similar tests.

Monolithic scenario vs. nitty-gritty detail tests

• Detailed, focused tests are more expressive at the cost of having more boilerplate.
• It can be a good idea to split your tests into multiple test classes.

Easyb vs. JUnit

• Easyb scenarios are still not editable by non-techies.
• Easyb's (Groovy) scenarios have less noise than JDave (Java), but there's still some.
• You could generate docs from the Easyb scenarios.
• Easyb seems more suitable for end-to-end or other higher level tests.

Mock vs. fake

• With mocks people often slice code into such small pieces that the tests just mirror the implementation.
• Mocking forces you to keep interfaces clean and focused.
• Mocking well is a skill!
• What if there's a bug in my fake?
• Extracting JMock expectations into private methods can make your tests more readable.
• Cluttered JMock expectations might imply a flaw in your design.