|
by E. L. Koba 03/11/2015, 5:00pm PDT |
|
 |
|
 |
|
Fullofkittens wrote:
Re: unit testing, Justin Searls wrote a couple of really fascinating posts about unit testing that really spun my hat around; I haven't thought about them in the context of testing test code but it seems like his approach, if it's valid, would be as valid on a UI testing project as it would be on anything else:
The Failure of Intro to TDD
Mock Objects in Discovery Tests
I frankly love this approach because it helps lead to the experience that I enjoy so much while using BDD: you do some upfront scaffolding to break down a big problem into smaller problems, and then you solve all the small problems in isolation and then... WTF?! The big problem is already solved! He alleges various other benefits too; I cannot vouch for them because (other than one simple API testing tool) I basically haven't done any coding in a year due to organizational churn, so I haven't had much opportunity to spend much time with it.
These are pretty good, and this is basically the way I work. Using tests to drive out my code has BY FAR increased the quality of my code since I took on the testing religion.
But, I am definitely in the "less mocking" camp. It drives me crazy when I dig into some code and find out that whoever wrote the test stubbed and mocked out almost everything in the method so that the test has almost no relation to what is actually going on in the code.
He claims that shouldn't do much code re-use because then if you have to make a change in a bunch of your tests. Generally I've found that if making a small change to your code requires changing a large number of tests, that means that either you are testing the wrong thing, or your code is wrong. If it's hard to test, it's time to refactor your code so that it is easy to test.
Maybe this is because it looks like he is writing everything as functions and not object oriented like god intended. But I guess that is just kids these days with their node.js.
|
|
 |
|
 |
|
|
|