I’ve put together a really good collection of posts, including tutorials for pytest, unittest, and nose, into an eBook format. Actually, three formats.
This book is still a work in progress…
What does that mean?
I’ve updated the posts on unittest introduction and fixtures.
The nose chapters, and pytest chapters are still a little glitchy.
However, with proceeds from the book sale to help offset the cost, I’m now writing on a nice laptop that will hopefully get me writing more.
So, Updates are coming.
If you buy now at $5, you’ll get notified when things get fixed.
Here’s what’s there:
– unittest introduction
* Overview of unittest
* Running unittests
* Test discovery
* unittest examples
– unittest fixture syntax and flow reference
* Software Test Fixtures
* Common Case Example
* Full Test Fixture Example
* Full Test Fixture Flow
* Adding Cleanup Calls
* Skipping tests within setUp
– nose introduction
* Nose example
* Running nose
* Nose fixtures
* Nose assert_equals * Test discovery
* Running unittests from nose
* Running doctests from nose
– nose support for unittest style fixtures
– nose fixture reference
* Method, Function, Package, Module, and Class fixtures
* Full example
* Control flow
* Alternative names for fixtures
– pytest introduction
* pytest example
* Running pytest
* pytest fixtures
* Test discovery
* Running unittests from pytest
* Running doctests from pytest
* Running nose tests from pytest
– pytest fixtures
* pytest unittest style fixtures
* pytest xUnit style fixtures
* pytest fixtures easy example
* pytest fixtures nuts and bolts
* pytest session scoped fixtures
Whatever your stance on the merits or pitfalls of Test Driven Development, I think it’s worthwhile and educational to pay attention to a discussion that’s going on lately.
Testing is crucial. But is unit test focused TDD the right path?
I care about the conversation about TDD because I see serious flaws in the conventional understanding of TDD.
Much of the current view of TDD includes:
- Units are tested in isolation of the rest of the system.
- Unit tests are more important than any other form of testing.
- A “unit” is a class or a function. Nothing larger is a “unit”.
- If you test more than one class, that’s an integration test.
- If you test from the API with all resources, that’s a system test. Let QA deal with that later. Isn’t that exactly where waterfall failed?
- You can’t write any production code without a failing test.
- You have to write only one test at a time, and it must fail.
- Tests have to be fast.
- Therefore, they cannot touch hardware, the file system, other services, or database.
- Tests should be short.
All of this rubs me the wrong way.
I’ll get to my thoughts later, but my concern about this cemented view of TDD caused me to be very interested in the current talks.
On to the discussion
I came in after the 2nd video, while doing research on Agile and TDD.
I’m not sure if the order matters, but here’s a list of what I know about the discussions.