On Sun, May 05, 2013 at 11:03:49PM -0700, Ovid wrote: > From: Buddy Burden <barefootco...@gmail.com> > >I lean more towards Mark's approach on this one, albeit with a slight twist. > Given the very interesting discussion and the fact that I hate dogma (such as > what I was throwing down), I have to say that I'm going to rethink my > position on this. Thanks for all of the informative comments, everyone!
I lean very much towards starting from a known state. I don't care what that state is, just that it's known. This is because I see the tests I write as being primarily a debugging tool, not merely a way of proving that what I've done is correct - we all know that tests can't do that, right? Debugging is easiest if you don't have to sift through loads of irrelevant noise to find the problem. It's a good point that the live environment is unknown, and potentially full of broken old rubbish from previous versions of the software. That is why we do two things: * first, when a bug gets reported in live, I like to create a test case from it, using data that at least replicates the structure of that that is live. This will, necessarily, be an end-to-end test of the whole application, from user interaction through all the layers that make up the application down to the database, and back up through all those layers again to produce broken output. As I debug and fix I may also create unit tests for individual bits of the application. * second, we don't just deploy from dev to live. We have a staging environment in which real people hammer on the application. Ideally, they'll record what they do and create repeatable tests completely independently of the developers. -- David Cantrell | semi-evolved ape-thing You don't need to spam good porn
