Hi list. Do test-driven development or behaviour-driven development advocate how to do higher-level testing than unit testing?
>From reading up on the subject, I see that there are formally these types of testing: unit integration system acceptance I'm asking about this, because as suggested by various posters, I have written my latest (small) app by following a Behaviour-Driven Development style. The small app consists of about 5 relatively simple classes, each with behaviour tests, and mocks for the other objects it uses. I wrote the tests before any code (I cheated a bit here and there, like adding logging before adding logger mocks and tests to check that the logging took place). That went well, and the code ended up much more modular than if I hadn't followed BDD. And I feel more confident about the code quality than before ;-) The testing module has about 2x the lines of code as the code being tested. My problem is that I haven't run the app once yet during development :-/ It looks like I've fallen into the trap described here: http://en.wikipedia.org/wiki/Test-driven_development#Fakes.2C_mocks_and_integration_tests Should I go ahead and start manually testing (like I would have from the beginning if I wasn't following TDD), or should I start writing automated integration tests? Is it worth the time to write integration tests for small apps, or should I leave that for larger apps? I've tried Googling for integration testing in the context of TDD or BDD and haven't found anything. Mostly information about integration testing in general. When following BDD or TDD, should one write integration tests first (like the unit tests), or later? Or don't those practices cover anything besides unit testing? Which integration test process should one use? (top down, bottom up, big bang, etc). Thanks in advance for any tips. David. -- http://mail.python.org/mailman/listinfo/python-list
