I used to work for a company that had a very strong engineering ethic and process. I was part of a large project that was based on a high level of development excellence. For example the unit test coverage minimum was 98%. For the most part, we were always above 99%, but occasionally fell below when new people/dev groups would join the project and were not familiar with our standards.
Enter CRAP
I think everyone would agree, keeping 98% code coverage is challenging. What if we could eliminate the need to write tests except where it really counted. CRAP (Change Risk Analysis and Prediction - now there is an acronym looking for a definition!), tries to help by identifying more complex code, or code that would be more at risk to change.
We used crap to eliminate unneeded unit tests and to gauge the amount of unit test coverage required for any particular function. It actually works pretty well. Getters, Setters, and 2-3 line functions (with little logic), also have no requirement for unit testing. That's how we defined it anyway.
We lowered our unit test coverage requirement to 90% and used CRAP to ensure complex functions were covered. Great right?
CRAP Thinking
In our case, the spirit of these changes was to eliminate trivial test requirements and focus on more relevant tasks. Unfortunately, some took this as a rule to be bent and broken.
One curious engineer figured out that if you keep all your functions to very simple 2-3 lines you won't have to write any unit tests. So they went about re-factoring their code in such a way so that there just weren't any functions longer than 3 lines.
How do you do that? You create functional binary handlers to combine the logic of other handlers and build up a kind of domain level syntax that you can use to formulate high level logic.
It's kind of brilliant really, if it hadn't been so insidiously underhanded. I mean, if they had published their technique as an open source project, they probably would get a following of similarly curious developers.
But that's not what was wanted in this environment. The code was (properly) rejected and the engineer had to abandon the technique.
