12/31/2009 05:34:24 AM EST

Thanks for the mention of our book. We too use functional tests to guide our development progress, but (obviously) we don't think that's enough. I've spent too much of my life trying to understand what failure a functional test has revealed because it's too high-level. I think it's perfectly fine for developers to spend time on their infrastructure--we're stakeholders too. Unit-TDD is not a luxury for me but a development tool that helps me stay focussed and keeps the code moving. It's true that certain kinds of refactoring are easier when there are fewer unit-level tests, but then I find that those codebases /need/ more refactoring. Obviously, Cedric, you and others have a different experience. There's an interesting counter-movement from people such as Arlo Belshee and JB Rainsberger, who are moving away from automated functional testing to just unit testing but Arlo, at least, has a sophisticated team that knows how to make that work.

United KingdomSteve Freeman

12/31/2009 05:41:47 AM EST

I would love to know what you think about "The art of unit testing" then. It's the only one out there *not* about tdd, but strictly about unit testing. it's .NET oriented, but I found it usable for Java as well.

United StatesJames Mccallen

01/01/2010 10:29:37 AM EST

I certainly agree: It seems redundant, to me, to qualify “Test-Driven Development” by saying that we write the tests first. How else could it be test *driven*? And, like you, I find it invaluable to focus on integration tests over unit tests. Unit tests are easier to write, but often fail to ensure that the system, as a whole, performs as expected. I think this has been known since the start of the practice, considering this quote from its creators: “End to end is further than you think.” – Kent Beck (Quoted in "Extreme Programming Adventures in C#" book, chapter 13, page 182 by Ron Jeffries) I think we should ask ourselves: Why would the founders of TDD say “End to end is further than you think.” if they were doing only unit testing? I illustrate the need for integration testing in my Java News Brief article “An Example of Test Driven Development with the Spring Framework.” The NullPointerException that occurs in the interaction between two units that have independently been unit tested is inspired by a problem that I encountered in production code written with TDD. Yes, the code coverage was good, but the integration between the units was not adequately tested. http://jnb.ociweb.com/jnb/jnbDec2009.html I practice and teach the value of automated integration testing. I believe that this has always been the real intent of the TDD practice.

United StatesJeff Grigg

01/01/2010 10:31:01 AM EST

P.S. I have also found that integration tests enable refactoring more than unit tests.

United StatesJeff Grigg

01/02/2010 05:29:35 PM EST

This is a very well written article. It appears that Andrew is primarily focused on Java testing but for those interested in PL/SQL unit testing, Quest Code Tester for Oracle is an automated PL/SQL code testing tool. Created by one of the world’s most prominent Oracle PL/SQL experts, Steven Feuerstein, Code Tester for Oracle delivers practical and thorough code testing. I hope this information is helpful to PL/SQL developers interested in functinal testing and TDD.

United StatesJoe

01/12/2010 06:46:37 PM EST

Andrew, thanks for this post and the reflections it has triggered. I think another key thing Cedric has said concerns test overlap. I have tried to explore, quantify and understand testing overlap and how they relate to the unit versus functional tests discussion in this post: http://blog.dossot.net/2009/12/is-test-overlap-necessary-evil.html

CanadaDavid Dossot

03/02/2010 10:42:58 PM EST

For years, I have used a mixture of both approaches to TDD: 1)start with a high-level test, 2) start with a low-level test. I choose my approach for a given story based on the highest risk. If I know my technology, then usually the risk of misunderstanding the requirements is highest, and thus I start with a high-level test. If the highest risk is not knowing my technology, I may start with a low-level test. If I REALLY don't know my technology, I may simply open up a separate project and play with it in a directed way to learn enough to plan intelligently. Some people call these a Spike story. If a developer is comfortable using both approaches, they can use their judgement to choose a level of testing that is the best approach for the situation. David Kreth Allen http://codecontracts.info

United StatesDavid Allen