Process documentation needed: automated test suite

[denise]

crschmidt pointed out in his bug walkthrough that the process of running the automated test suite is not very well documented! And I agree; I know I don't run the tests when I'm patching things since I don't really know much about it, and I don't contribute tests along with my code because I actually don't know how to write them or what they should do. I am probably not the only one! (The only thing I know about the test suite is that you shouldn't run it in production because it does weird and wonky things to the database.)

I do know that our test suite coverage is not extensive at all, and we've talked before about moving to a more test-driven devlopment mindset. If anybody wanted to write up some documentation on the Wiki about both how to run the tests (and what you should look for) and how to write new tests (and when you should), that would be awesome and I would love you forever. (Well, I mean, I love you all forever already. But I'd love you more forever.)

Comments

[fu]

* Yes to setting up a different database for testing. This is how other testing suites are run. This is how we should do it as well.

* Hmm, yes to a more developer-friendly test framework. I don't have the time to commit my time fully to this, but at a glance, this basically means we'd be writing tests as more of... data input, rather than writing code right? I think that would be immensely helpful.

* Yes, I think that would be good practice. If nothing else, it could be a good way to train people to get as far as checking out the codebase and submitting a patch. Maybe good to check whether it works for other projects though before we dive in?