After adding many unit tests, today I found myself cheating a bit. I'm attempting to retrofit tests to classes and methods that are responsible for way too much. So picture class A which is not written through TDD methodology. The new functionality in class B is being written through TDD. What I was able to do was to write good (-ish) tests for class B, but for class A, I found myself writing way too much setup code.
I'm curious how the process will work out, but I wound up writing somewhat long unit tests to meet the point of the test. The tests are reliant on actions A, B, and C occurring before the actual thing that was being tested. So I wrote some helper methods, but I worry about one thing breaking taking down the tests like a house of cards.
This seems like a no-brainer for more of a BDD style of testing, but only more investigation will tell. One bright note is that code coverage went way up, since tests touched a large number of deeper library methods.