I certainly don't. I have several different groups of tests, some of which run faster than others, and that's what work with. For example, at my day job, some of my current options are:
1. Database reload and database functional tests (2 seconds) 2. Run all ruby unit tests, without a database reload (2 seconds) 3. Run functional test of a program written in ruby, without database reload (1-2 seconds) 4. Database reload, run ruby unit tests, another reload, run all functional tests of programs written in ruby (7-10 seconds) 5. No database reload, start web server, run test cases from one class in the web test case suite (5 seconds, for the one I just tried) 6. Database reload, start web server, run all web test cases (30 seconds or so) 7. Everything (45-60 seconds)
Now it's a small system, but I've also done a lot of optimization of how I test over the years. (Switching from Java and HttpUnit to Ruby and test/httpweb for the web tests made them about an order of magnitude faster, as well as easier to write.)
I move stuff around between different kinds of testing as well, based on speed and convenience. (Some of my servlets are tested with unit tests in order to reduce the number of (slower) web tests, for example.)
The comment about "if it accesses a database, it's not a unit test" really irked me. Databases have code in them too, and that code should be tested just as you test any other code. I regularly migrate code back and for between, say, Ruby and SQL stored procedures, based on what's easy, what kind of security I need, and so on. In fact, I'll go so far as to say that your database schema *is* code, and should be treated as a first class citizen along with all of the rest of your code. (BTW, there's a bit of my unit test framework for PostgreSQL available in the pgtools project on SourceForge. Bug me and I'll update it.)
Flat View: This topic has 50 replies
on 51 pages
[
«
|
131415161718192021
|
»
]
Previous Topic
