I think we must be agreeing to disagree here, or we are agreeing to agree and missing it entirely in the translation.
My post was to highlight that there is an art to writing good automated tests that no tool will help you with - I deliberately didn't mention TDD as that is another art in it's own right.
If anything - tools are the problem here - a bit more focus on some really basic principles would pay off long before a few integration tests on badly written code.
When you can write a clean set of unit tests that have real value, you won't need to be writing code that is tightly coupled, nor would you want to ... or ....
Honestly Roy, would you write new code that is tightly coupled knowing you can fall back on tooling, or would you write it by nature in a loosely coupled way? To me both have the same up front effort, the loosely coupled way pays large dividends later on (like today when we had to consider moving our application search engine to another server, which will be nearly trivial due toit all being loosely coupled already)
I think that you've found the crux of it: a path of “all or nothing”. which for most people begets “nothing”.
Oh man. I hope you're asbestos undies are fully deployed.
One can tell by the vehement responses of many people against this idea that the idea strikes them on some sort of emotional level.
I'm really not sure what the fear is that is causing a reaction that seems out of proportion to the gvien the subject matter. Sure, I don't want to have to come behind noobs and clean up their code, but why all the emotion?
It's very surprising to see the vehement and sometimes caustic responses to what, in a nutshell, is the idea of breaking things into more granular pieces. Sure, it's not optimal, but to imply that one who learns to ride a bicycle with training wheels will be unlikely to then learn how to ride a motorcycle seems a bit paranoid.
Risking teaching noobs unit testing without a good understanding of OOD techniques such as SOLID, etc. is not going to place us in a worse situation than we have now where the noobs aren't even creating the first unit test.
I've been reading this discussion with a lot of interest. I'm someone who would love to do unit testing but the barrier to entry is much too high. 90% of the code I write interacts with outside resources (database, active directory, files, etc.) I'm told you can't unit test that - those are integration tests.
When I look for information or examples on unit testing, I either have to buy into all of the methodology (TDD, SOLID, etc.) or I'm told that what I need to test isn't unit testable.
I would love to see a good example of how I could write unit tests for the Active Record pattern. We have 100s of classes that instantiate an object that represents a row in the database with methods to insert, logical delete and update a row. The classes also have a number of shared methods that return a table of rows that match some criteria. How in the heck do I unit test that? Once we get that data we bind it to a grid. Again, where's the unit test there? It's n-tier. The data comes from sql, via a business tier to the presentation. So if you'd like to make some progress with one company with about 50 developers, show me how to do that, and we'd get 50 people doing unit tests.
I'm tired of seeing unit test examples on how to verify that something calculates price correctly. How do I unit test that my log message made it to the database?
I could even get my management to buy into letting us have time for the learning curve, if I could come up with a plan and some solid examples that our more junior developers can model. But, until I find them, we'll just bumble along without unit tests because what's out there takes too much time to assimilate.
I think we've lost sight of our priorities in the agile movement. Roy Osherove helps to redress the balance in his recent recent series of posts on unit testing. But my concern isn't just about making the tools approachable. The much bigger issue is...
I had a little time today, so I downloaded Isolator 5.1.
I've used TDD on previous projects, but on my latest one, there are only UI automation tests.
I looked for something to test in the project and the thing I picked definitely doesn't follow all of SOLID, among other issues, it uses the HttpContext.Current directly.
It took a little time, but I was able to get a test up and running; If I write a few more of these test, I'll be able to refactor the design to something a little more solid.