I want to share with you my approach to unit testing.
I used to write fairly low level tests against my classes. Eventually I realised they had little useful meaning other than checking for null pointers.
What I do now is make heavy use of mocking. I push back on the BA for a set of test cases. I push the opinion that I cannot realistically guarantee/test every permutation of the program works. So i get a set of test cases from the BA and I encode them in my unit tests. My unit tests read like a spec, I make them read like a English prose, abstracting out the details into builders. Once they pass, we are done. That is the contract between me and the BA.
To implement these kind of tests takes a lot of skill with the mocking tools. And often you are pushing the BA (or user) for test cases.
Ok, these aren't strictly "unit tests" but they are damn useful. Any issues down the track I can run my tests and my back is covered , because my unit tests document whys the BA signed off on.
I used to write fairly low level tests against my classes. Eventually I realised they had little useful meaning other than checking for null pointers.
What I do now is make heavy use of mocking. I push back on the BA for a set of test cases. I push the opinion that I cannot realistically guarantee/test every permutation of the program works. So i get a set of test cases from the BA and I encode them in my unit tests. My unit tests read like a spec, I make them read like a English prose, abstracting out the details into builders. Once they pass, we are done. That is the contract between me and the BA.
To implement these kind of tests takes a lot of skill with the mocking tools. And often you are pushing the BA (or user) for test cases.
Ok, these aren't strictly "unit tests" but they are damn useful. Any issues down the track I can run my tests and my back is covered , because my unit tests document whys the BA signed off on.
Comment