> One thing that is interesting about this thread is that > many are irked by the def of UTs that I laid out. The > thing is, I'm not trying to change the def in the > industry. But locally, with some teams, it's a great way > to focus.
I guess my issue with that is that it's just one way to focus, and it may be the wrong way to focus. In particular, I've worked with people who make comments like this:
Besides being slow, critical dependencies also have another nasty property: We can't ensure the availability of the resource being dependent on.
Sure, one approach is not to do those tests. But another is to figure out how you *can* ensure the availability of that resource. Often it requires getting pretty creative. A few years ago it even required moving an entire project from Oracle to PostgreSQL, so that everybody could have their own database server, with as many schemas as they wanted. That took a lot of work and negotiation, but it was well worthwhile in the end, because not only did the database stop being a "critical resource" that was blocking testing, but it in fact was brought into the agile world, letting us make database changes almost as easily as other code changes. I've done other creative solutions for things such as e-mail sending and receiving and external credit card transaction servers.