This question appears to be off-topic. The users who voted to close gave this specific reason:

"Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – Thomas Owens

hard to answer your question. there are many projects that utilize automated tests, but it's hard to say how far they follow the TDD philosophy because they probably don't promote it. also c++, c# and java kinda have their roots in gui applications, which are difficult to test. usually you will find more tests within frameworks or libraries.
–
iMacUwhAKDec 5 '10 at 19:52

Part of the reason why I am very interested in finding a good answer is that I'm currently working on a desktop application with a C++ engine and a Java GUI...
–
Xavier NodetDec 6 '10 at 7:37

6 Answers
6

JUnit was developed 100% test-driven. In fact, it was developed 100% test-driven in JUnit, which as Kent Beck has said a couple of times was a truly mindbending exercise.

I believe Sun's ZFS filesystem was developed test-driven.

The ikj interpreter for the Ioke programming language (JVM), the ikc interpreter for the Ioke programming language (CLI), the entire Ioke core and standard library, and in fact the language itself was developed 100% test-driven (actually behavior-driven).

As of version 3.7.14, the SQLite library consists of approximately
81.3 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.)
By comparison, the project has 1124 times as much test code and test
scripts - 91421.1 KSLOC.

heavily tested does not necessarily mean it was developed in a test-driven (TDD) manner. Was it? (I didn't read that whole page, but I saw neither "TDD" nor "driven" in in-page searches, so I don't know the answer to this.)
–
lindesDec 5 '10 at 22:01

1

@lindes: they seem not to follow TDD strictly, but for example for every bug report they firstly make a test. Also they run tests for every commit. So at least partially this is TDD.
–
lioriDec 5 '10 at 22:22

Have you - or others - shared these experiences? Sounds like a good war-story.
–
user1249Nov 27 '10 at 17:45

i've tweeted a bit about it, and used anecdotes to illustrate points in other posts. suffice it to say that test-first design and automated test suites make my life so much easier i would not go back and do development any other way. Example: subtle bug in one test case that manual testing would not have found (because the manual testers don't check database integrity after every operation); ran test case many times that day to figure it out, equivalent to over 40 hours of manual testing time saved. recently made over 1000 code changes and ran the tests while i slept. TDD rocks.
–
Steven A. LoweNov 27 '10 at 17:51

I believe you. I just like to hear the stories. You might find QuickCheck interesting - en.wikipedia.org/wiki/QuickCheck - I saw a presentation that found multithreading bugs in 15 year old production code.
–
user1249Nov 27 '10 at 18:54

"because the manual testers don't check database integrity after every operation" - constraints and a well designed DB schema rocks more, and would have saved you all that bother of having to spend a day testing as you'd have seen the bug immediately.
–
gbjbaanbMar 31 '13 at 19:23

@gbjbaanb: in this case, the 'check' was far more complex than simple schema integrity, that's why there's an automated test for it
–
Steven A. LoweMar 31 '13 at 20:02

I pulled down Enterprise Library 5.0 and had a look at the source code. It does have an extensive collection of tests, but there's a lot of test fixture, call handler and other complex objects in the test project; it seems almost like an application in its own right. While I admire the work, I don't see how it fits into the TDD world view of red-green-refactor.
–
Robert HarveyNov 26 '10 at 23:42

@Robert - I can only tell you what they told me... They used TDD when writing it.
–
WalterNov 27 '10 at 13:22

6

@Robert - It is not unusual for the test suite to take on a life of its own. DRY applies to both your application and the tests. In TDD you are only ever doing 1 of 4 things: Writing tests, writing code, refactoring tests, refactoring code. If you are doing all of these things in a red-green-refactor pattern, then you are doing TDD.
–
Jeff KnechtNov 27 '10 at 18:55

1

@Jeff: Thanks for clarifying that. I think there are some differences between the way TDD is explained (in reductionist, mechanistic terms), and the way it is actually used in real-world scenarios.
–
Robert HarveyNov 27 '10 at 19:08