I'm building a startup with Python and Pylons - Pylons comes with paster (python web server) and a small unit testing hook for your app; pylons makes it so easy to test your application, I love it. You can write two types of tests: functional tests and unit tests.
I split functional tests into the tests that actually make a web request (by spawning paster, loading the application, and pretending to be a user) - my lowest "unit" there are my controllers. I have to have some special trickery to handle sessions, but it isn't bad, beats having no tests.
My "unit" tests are a bit less fine-grained than yours are. I've had difficulty narrowing tests down below the module level with anything but libraries; primarily because models (the culprits here) have a few interdependencies. I do my best to keep my models orthogonal but not all of them are, so most of my unit tests are basically testing models as they operate on the database tables and some of their assistant methods.
If I write a library, I generally try to determine whether it can be its own "module" or should be a module within the application namespace. For example, I wrote an authorize.net payment library and ultimately decided that it should have its own tests - separate from the application, which lead me to splitting it off as its own project (PayPy now, with adapter support for some other gateways). Writing some of the library modules in their own namespace with their own tests keeps it clean orthogonal.
Overall, I would say this: I'm not as OCD about writing tests as you are because I'm the sole developer and there are too many features to build to be writing functional tests every time I build a controller. My philosophy is this, though: the models should all be covered, no matter what; since they are the messiest bit of logic (usually) in a web application - translation between relational data into object oriented data has a lot of side effects. Having all models covered ensures that the majority of my logic that interacts with the database is solid. It also keeps any schema/model changes in check that may affect other models I've forgotten about.
After that, I try to make sure any critical controllers/pages/functional pieces are covered - the really trivial stuff I worry less about and just make sure it "works right" by doing some manual testing myself before pushing it.
I love functional/unit testing - I will never go back. My old way of development feels like I was lost in the dark ages of my career or something...
I split functional tests into the tests that actually make a web request (by spawning paster, loading the application, and pretending to be a user) - my lowest "unit" there are my controllers. I have to have some special trickery to handle sessions, but it isn't bad, beats having no tests.
My "unit" tests are a bit less fine-grained than yours are. I've had difficulty narrowing tests down below the module level with anything but libraries; primarily because models (the culprits here) have a few interdependencies. I do my best to keep my models orthogonal but not all of them are, so most of my unit tests are basically testing models as they operate on the database tables and some of their assistant methods.
If I write a library, I generally try to determine whether it can be its own "module" or should be a module within the application namespace. For example, I wrote an authorize.net payment library and ultimately decided that it should have its own tests - separate from the application, which lead me to splitting it off as its own project (PayPy now, with adapter support for some other gateways). Writing some of the library modules in their own namespace with their own tests keeps it clean orthogonal.
Overall, I would say this: I'm not as OCD about writing tests as you are because I'm the sole developer and there are too many features to build to be writing functional tests every time I build a controller. My philosophy is this, though: the models should all be covered, no matter what; since they are the messiest bit of logic (usually) in a web application - translation between relational data into object oriented data has a lot of side effects. Having all models covered ensures that the majority of my logic that interacts with the database is solid. It also keeps any schema/model changes in check that may affect other models I've forgotten about.
After that, I try to make sure any critical controllers/pages/functional pieces are covered - the really trivial stuff I worry less about and just make sure it "works right" by doing some manual testing myself before pushing it.
I love functional/unit testing - I will never go back. My old way of development feels like I was lost in the dark ages of my career or something...