Comments on: Test Doubles: When To (Not) Use Them http://davybrion.com/blog/2008/08/test-doubles-when-to-not-use-them/ Trying to walk that thin line between intelligence and ignorance Sat, 13 Mar 2010 21:19:34 +0100 http://wordpress.org/?v=2.9.2 hourly 1 By: Nocturn vision » Blog Archive » Introduction to test-doubles http://davybrion.com/blog/2008/08/test-doubles-when-to-not-use-them/comment-page-1/#comment-9987 Nocturn vision » Blog Archive » Introduction to test-doubles Mon, 16 Mar 2009 18:59:26 +0000 http://davybrion.com/blog/?p=305#comment-9987 [...] doubles by Martin FowlerxUnit Test Patterns by Gerard Meszaros (also check out the website)Test Doubles: When (not) to use them by Davy [...] [...] doubles by Martin FowlerxUnit Test Patterns by Gerard Meszaros (also check out the website)Test Doubles: When (not) to use them by Davy [...]

]]> By: Reflective Perspective - Chris Alcock » The Morning Brew #159 http://davybrion.com/blog/2008/08/test-doubles-when-to-not-use-them/comment-page-1/#comment-1159 Reflective Perspective - Chris Alcock » The Morning Brew #159 Fri, 15 Aug 2008 07:19:28 +0000 http://davybrion.com/blog/?p=305#comment-1159 [...] Test Doubles: When To (Not) Use Them - Davy Brion gives some guidance for choosing when to use the real component and when to use a test double in its place when writing tests. [...] [...] Test Doubles: When To (Not) Use Them – Davy Brion gives some guidance for choosing when to use the real component and when to use a test double in its place when writing tests. [...]

]]> By: Dew Drop - August 14, 2008 | Alvin Ashcraft's Morning Dew http://davybrion.com/blog/2008/08/test-doubles-when-to-not-use-them/comment-page-1/#comment-1151 Dew Drop - August 14, 2008 | Alvin Ashcraft's Morning Dew Thu, 14 Aug 2008 13:50:04 +0000 http://davybrion.com/blog/?p=305#comment-1151 [...] Test Doubles: When to (Not) Use Them (Davy Brion) [...] [...] Test Doubles: When to (Not) Use Them (Davy Brion) [...]

]]> By: Davy Brion http://davybrion.com/blog/2008/08/test-doubles-when-to-not-use-them/comment-page-1/#comment-1150 Davy Brion Thu, 14 Aug 2008 05:43:35 +0000 http://davybrion.com/blog/?p=305#comment-1150 true, up to a point. We currently have 2 projects at work where practically all of the tests use the database. One has about 11000 tests, and the tests take 20 minutes to run. Nobody runs the tests on their own machine, they always wait for the buildserver to run them. Apart from being horribly slow, the developers of that team actually do a great job of keeping that build 'green' as much as possible. Still, i would much rather see them having a test suite that can be ran by anyone at any time without wasting time on it. The second project has about 7000 tests, which take about 10 minutes to run. The biggest problem with this project is not the time wasted running the tests, but the time wasted on writing the setup for each test because they have a horribly complicated data model. For every new test, they are wasting a lot of time just to be able to write tests. There's also a large maintenance cost involved... i've heard some developers claim that they often spend 4 hours or more fixing/modifying tests that are related to a fix/modification in the code which only took them about an hour to do. Those tests are also extremely fragile, up to the point where i'm actually suprised if the project has a completely green build. It doesn't happen often. And it never lasts long. true, up to a point. We currently have 2 projects at work where practically all of the tests use the database. One has about 11000 tests, and the tests take 20 minutes to run. Nobody runs the tests on their own machine, they always wait for the buildserver to run them. Apart from being horribly slow, the developers of that team actually do a great job of keeping that build ‘green’ as much as possible. Still, i would much rather see them having a test suite that can be ran by anyone at any time without wasting time on it.

The second project has about 7000 tests, which take about 10 minutes to run. The biggest problem with this project is not the time wasted running the tests, but the time wasted on writing the setup for each test because they have a horribly complicated data model. For every new test, they are wasting a lot of time just to be able to write tests. There’s also a large maintenance cost involved… i’ve heard some developers claim that they often spend 4 hours or more fixing/modifying tests that are related to a fix/modification in the code which only took them about an hour to do. Those tests are also extremely fragile, up to the point where i’m actually suprised if the project has a completely green build. It doesn’t happen often. And it never lasts long.

]]> By: anon http://davybrion.com/blog/2008/08/test-doubles-when-to-not-use-them/comment-page-1/#comment-1149 anon Thu, 14 Aug 2008 04:34:22 +0000 http://davybrion.com/blog/?p=305#comment-1149 The problem we found is that developers are too used to working closely with databases, so when we introduced unit tests, a lot more tests than was necessary had db dependancies. Of course this doesn't scale well, takes a lot more setup/teardown work and is generally a bad idea, but the hard part is convincing people that separation of concerns (and single responsibility principle) is often the root cause of this database dependency problem. One person I work with has adopted (db dependent quasi-unit) testing and loves it, so I don't want to discourage them. I'd rather have slow tests than no tests at all. The problem we found is that developers are too used to working closely with databases, so when we introduced unit tests, a lot more tests than was necessary had db dependancies.

Of course this doesn’t scale well, takes a lot more setup/teardown work and is generally a bad idea, but the hard part is convincing people that separation of concerns (and single responsibility principle) is often the root cause of this database dependency problem. One person I work with has adopted (db dependent quasi-unit) testing and loves it, so I don’t want to discourage them. I’d rather have slow tests than no tests at all.

]]>