Untestable code
Untesttable Code? Bullshit
Testing Talk at CITCON Perth August 5, 2016
Is this the right title?
Michael Feather's definition for unit testing http://www.artima.com/weblogs/viewpost.jsp?thread=126923
Unit tests for only Public methods? If you are testing the public methods, then you should be able to cover the private methods
PJ follows a very strict TDD workflow: 1. Write a broken unit 2. Just enough code to make the test pass
a. PJ will proactively unecessary code
3. Refactor 4. Repeat
Do you refactor just production code?
No, PJ refactors everything. In fact, he's been know to say that the unit test suite is more valuable than the production code. Because given a "good unit test suite", I can recreate the production code. However, given the production only, I cannot usually create a "good unit test suite".
Do you use coverage checking? Yes, always. As part of the CI pipeline.
Do you break a build on coverage? Yes. I always break the build if the covereage goes down from the last successful
Principle: A broken build is a promise to have a discussion.
Do you delete unit tests?
Yes. I frequently refactor unit tests and elimate specifc tests because they have become redundant.
Since I write my unit tests in a BDD style, I sometimes leave redundant tests in place just for their documentation value.
Is BDD too high level for unit tests? No. It depends on what level of Behaviour you are expressing. In the unit test scenario, I am usually expressing the behavior of a function/method/package. Whereas in testing the overall function of an application/service/module/plugin the language is usually closer to the domain language.
If you have a big bucket of code (legacy code), should we go about creating unit tests for all of it? No. Generate a test suite that expresses the current behavior.
In practice, PJ creates unit tests for the new features/bug fixes that he implements.
Example:
Tibco plugins
Message Oriented Middleware - Close to no coding. Dragging and dropping widgets. System Integration orchestration.
PJ was writing widgets back in 2000.
How to TDD for a System Integration platform that is not inherently "code" based.
PJ follows a very strict ATDD workflow:
1. Write a broken acceptance test
2. Just enough code to make the test pass
a. PJ will proactively unecessary code
3. Refactor 4. Repeat
PJ likes Cucumber, Lettuce, Specflow (for .Net), Gherkin is the language, Cuke for Nuke
Acceptance test format:
Given [a certain state exists already] When [something happens] Then [the state should be...]
We are going to use TIBCO to integrate our Payroll system and our Reporting system
Given that it is the end of the month When payroll has been finalized Then a report showing all the employees that have been paid exists.
PJ will run the 3 lines above through Cucumber. The tool prints out 'Hey you are missing code that describes "that it is the end of the month"' It also usually provides a "code template" for me to fill in.
That is the end of the month We need to be able to simulate "end of the month" or perhaps we want to change the clause to "Given that payroll as been processed"
We are running out of time to finish this example...
A note: Many companies are now using more "monitoring" to test that this happened correctly. However, we will use tests to make sure that the pieces, like putting the message onto the tibco MOM.
Monitoring is more valuable than testing! Because, testing might indicate that something works, but it still may fail in production.
