Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Test Driven Development Examples? 74

Posted by Cliff from the seeking-verification dept.
esnyder queries: "I find the pragmatic/agile/XP hype about test driven development compelling, but find it hard to see how to test first (or even unit test at all) in some situations. I would like to explore some extended examples of it in a moderate to large scale real world codebase to improve my test design skills. Can anyone recommend some F/OSS software projects that consistently use test driven development processes that I could check out? Preferable over 50K lines of code, but I'd welcome pointers to anything that people think would be helpful."
This discussion has been archived. No new comments can be posted.

Test Driven Development Examples? More

Test Driven Development Examples?

Comments Filter:

  • eating your own dogfood (Score:3, Insightful)

    by anomalous cohort ( 704239 ) on Thursday February 12, 2004 @07:02PM (#8263706) Homepage Journal

    Nothing reality tests the usability of a proposed API then writing unit tests against it.

    For those who develop in Java, may I propose JUnit [junit.org]? If you want to test the GUI of a web server, then try HTTPUnit [sourceforge.net] although the value of writing unit tests to this is less since GUI is usually subject to a lot of changes over time.

  • Zope3 (Score:3, Informative)

    by eukreign ( 125727 ) on Thursday February 12, 2004 @07:03PM (#8263714)
    Take a look at Zope3 it has some 5,000 unit tests:
    http://cvs.zope.org/Zope3/ [zope.org]

  • Start Small And Move Up (Score:5, Interesting)

    by Bloodshot ( 8999 ) on Thursday February 12, 2004 @07:05PM (#8263743) Homepage
    Where I work we're coding a dating site. Currently, it's up to about 180K lines of scripts written in PHP. However, not a lot of it was written with unit testing (and test-driven development) in mind. I'm a big believer in unit testing but it's been hard to get the other members on board as they complain how hard it is to write unit tests for web pages. Bah.

    So, most of the library functions that I wrote (stuff like except an integer, return a text string from a list) have been unit tested by myself, and every time I change a function or a class, I try and write a unit test for it.

    Seriously, you just need to dive right in and think about how you make your code easy to test. I use the SimpleTest testing framework (it's PHP), and I always feel good when my array of tests all run correctly when I make a major change to the code that impacts a huge portion of the site.

    If test-driven development has done one thing, it's forced me to carefully examine my code to create a way to make sure it is actually working according to the business logic we've been asked to implement.

  • Darn good question. (Score:4, Insightful)

    by Godeke ( 32895 ) * on Thursday February 12, 2004 @07:07PM (#8263786)
    None of the projects I have looked at appear to have test first design. Some (especially CPAN items) have good testing of the functionality in place, but these are all modules inside a programming language. I have never seen a full on stand alone project with such testing built into the core.

    I find that odd really, considering that the point behind "write tests first" is to create an executable specification for functionality. If a new piece is desired, surely it would be easier for someone else to pick up the module with the tests and write code to pass the tests than it is to try to pick up the flow of a project from out of date documents, etc, and just contribute. I look forward to those who know of such projects, because I plan to examine them for help on how to implement these techniques myself. (My current project uses regression tests driven by an external test application... I have had this same question for some time, especially in regards to web applications).

  • Python (Score:5, Informative)

    by mbrubeck ( 73587 ) on Thursday February 12, 2004 @07:08PM (#8263800) Homepage
    The Python programming language [python.org] and all of its standard library modules make extensive use of unit tests and TDD.
    • Add Tcl and Tk to the list:-) They have a big test suite which pokes and prods at as many nooks and crannies of the language as possible.
  • Twisted is a networking framework in Python which has a lot of unit tests:
    http://www.twistedmatrix.com [twistedmatrix.com]

  • Java example (Score:5, Informative)

    by jtheory ( 626492 ) on Thursday February 12, 2004 @07:10PM (#8263818) Homepage Journal
    It would have been helpful if you'd mentioned the language you're using, and the types of applications (since of course both of those make a huge difference).

    If you're using Java for web development, I'd suggest reviewing the Struts Applications Project on SourceForge [sf.net].

    It's a collection of documentation and applications using Struts that are really "done right" -- with documentation, sensible and scalable design, fully implemented testing (unit level AND on the HTTP level). I'm currently roaming through the AppFuse source in there -- it's basically designed to give you a complete setup to start building your app on, with common functions already built-in.

    From the site:
    AppFuse
    An application for starting your Struts-based applications. Checkout from CVS and execute "ant -Dapp.name=yourApp -Ddb.name=database" to instantly be up and running with a Tomcat/MySQL app. Uses Ant, XDoclet, Hibernate, JUnit, Cactus, StrutsTestCase, Canoo's WebTest, Struts Menu, Display Tag Library, JSTL and Struts (including Validator and Tiles). Features include CMA, Remember Me, Self Registration, Password Hint. The fuse to start your apps.
    • Mostly I write C++, Java, PHP and Perl. But I didn't want to limit the question by language, since I'm interested in pretty much any project using the methodology regardless of implementation platform. Thanks for the Struts Applications pointer!
    • Practically every subproject (and derivatives) of the Apache Jakarta [apache.org] project uses automatic unit test suites as part of their build systems, whether with the Ant, Maven or Forrest tools.
  • http://www.kernel.org/

  • TDD vs. unit tests (Score:4, Informative)

    by Nevyn ( 5505 ) * on Thursday February 12, 2004 @07:24PM (#8263982) Homepage Journal

    I'm far from convinced that TDD is actually a good approach. Although it's pretty obvious that without testing the code is often trivially buggy, and unit testing is the cheapest way to perform testing. For instance this kind of thing [msdn.com] is all too easy to do with TDD.

    For unit tests you want to write your code, and then look at the best set of unit tests to do complete code coverage. For an OSS e3xample of that you can look at Vstr string library [and.org] and the code coverage [and.org] for that project.

    • If you look at the code coverage report for the parent example, you'll see that a common cause of less than 100% code coverage is multiple return points in functions.

      Multiple return points usually occur because the algorithm computes the return value 'early' (often via some special condition) or because an error condition is encountered and the return mechanism is used to propagate errors up the call hierarchy.

      If you write your function to have only a single return point at the end of the function, you ca

      • If you look at the code coverage report for the parent example, you'll see that a common cause of less than 100% code coverage is multiple return points in functions.

        That's a simplification, a significant portion of it now seems to be gcc coverage bugs (Ie. lines marked not covered I can step through in a debugger), but yes a lot of the difficult areas are to do branches.

        If you write your function to have only a single return point at the end of the function, you can increase the code coverage, whi

        • If one was aiming for readability, one obviously wouldn't write the gibberish in your example :-)

          We didn't hit 100%, because there was code that would only be run if hardware-centric exceptional cases were encountered. In such a case, exception code was executed, which we could test via a test harness, but the

          if(exceptional_state) do_exception();

          code did not get covered. I think we managed above 95%, which were we were pretty happy with. I don't recall the ratio of lines of code to lines of tests.

  • My main OSS project is a window manager. How do you unit test that? It is nearly impossible without writing your own test X server and the like. Just not worth it.

    We write or bring in small programs which test how we handle applications or events. But it is still really hard to test the whole thing.

    • Re:some projects are hard (Score:3, Informative)

      by Nevyn ( 5505 ) *

      My main OSS project is a window manager. How do you unit test that? It is nearly impossible without writing your own test X server and the like. Just not worth it.

      Creating mock objects [sourceforge.net] is much simpler than creating a "text X server", although admitedly a wm is slightly harder than normal as you can't take the easy route of running a seperate version on your main display.

      Howewver taking a quick look at blackbox, textPropertyToString() is the only thing in Util.cc that couldn't trivially be unit test

      • yeah, Util.cc and to some degree the rest of lib/ is easy. I tend to think more about the wm (which is where we have most of the problems).

        This kinds of pushes me to try testing more of the lib though ......
    • Isn't there an X server that's designed for testing? Or, perhaps you could write a simple application that interacts with your window manager, and your application can ask the window manager to do something, and then verify the result.

      But you're in the arena of gui testing, which is hard. Everyone admits that it's hard. But for many applications, you can separate the gui from the parts that do the real work, and then test those parts. In some cases this can even give you a huge benefit in terms of prog

  • I keep junit around (Score:5, Insightful)

    by ReciprocityProject ( 668218 ) on Thursday February 12, 2004 @07:55PM (#8264288) Homepage Journal
    I'm sure a lot of people have grounds to object, but I suggest, depending on the nature of the project, it's a good idea to be intelligently selective about what does and does not need to be unit tested. Consider:

    Do write a test case if:

    + a failure could introduce data propagation issues
    + it performs some intricate mathematical or logical function whose result must be precise
    + you're writing test cases to hunt down bugs that you know are in you're code; keep those test cases
    + you're uncomfortable about the quality of your code
    + an error might kill someone, or otherwise be Really Bad

    Don't bother writing a test case if:

    - you can use a guard clause or assertion instead
    - a failure in the code will otherwise be immediately obvious
    - the code generates massive amounts of data which need not be mathematically precise (i.e. graphical output)
    - you don't feel it

    I should probably write more test cases, according to my own guidelines. ::sigh::

  • The Bowling Game (Score:4, Interesting)

    by rlowe69 ( 74867 ) <ryanlowe_AThotmailDOTcom> on Thursday February 12, 2004 @08:31PM (#8264674) Homepage
    The first wow, that's cool moment I had with test driven development was from an article on Object Mentor called The Bowling Game [objectmentor.com]. It also highlights pair programming a bit.

    The unique thing about the article was that it was presented as a discussion between two developers pair programming doing agile test driven development of the game. It was like watching over their shoulders.

    If you want to get an idea of what extreme programming is like, I suggest reading this article AND writing the code and tests along with it, either in Java (and JUnit) or C#/VB.NET (and NUnit) or another language with a xUnit unit testing framework [junit.org]. Most object oriented languages have them now so you don't have to roll your own framework.

  • SCons (Score:3, Informative)

    by scons ( 633185 ) on Thursday February 12, 2004 @09:48PM (#8265360)
    On the SCons [scons.org] project, we've been heavy users of a Test-Drive Development methodology from day one of the project (coming up on three years now).

    SCons is a next-generation build tool, or make tool, written in Python with strong cross-platform support, integrated autoconf-like functionality, a lot of stable features, and a growing user community. We're currently at 14K+ lines of non-comment, non-blank source code, and 32K+ lines of non-comment, non-blank test code.

    We use a combination of two different testing methodologies: 1) Individual modules all have PyUnit unit tests (similar to JUnit, but in Python, of course). 2) The SCons application itself is tested using a custom testing module that manages creation of temporary directories and files, execution of the application, and checking against expected results. This custom module is actually a wrapper around a generic "test any script/command" infrastructure module that could be easily used to test other scripts and/or commands. (The command under test could be implemented in any language, not just in Python.)

    I use the Aegis [sourceforge.net] change management system to manage the SCons development and testing cycle. Aegis' primary value add (for me) is its management of the test cases and the testing methodology it enforces. By default, all Aegis changes must have one or more modified or new tests. The new/modified tests must not only pass when run against the new code, but must (by default) fail when run against the old code. This helps guarantee that your tests are good, and that your code isn't passing because you made a mistake in your test and forgot to call the new feature.

    By testing in this fashion from day one, we've built up a very strong regression test base--284 test scripts at last count, each script containing multiple individual tests. This test base has become crucial to our ability to refactor (and refactor and refactor...) the internals as we add more features. Sometimes it takes longer, of course, to make a rewrite satisfy all of the regression tests, but when you're done, you can be pretty sure you haven't broken anything. And if you did break something, then you have to add or modify a test when you fix it, and that becomes another part of the regression test base.

    The key to getting going with this kind of test-driven development (in my opinion) is making writing and executing the tests as simple as possible (but no simpler!). If writing a test is too difficult, then a lot of developers will simply avoid it. But if you can get them over the initial hump by making it easy to write tests, it gets downright addictive because you get all of this positive feedback when your tests show you that your new code works.

    We'd be glad to have you check out the testing infrastructure we've developed for SCons, either for code you can actually use, or simply as a source of ideas. Feel free to contact the SCons development team if you have any questions.

    • Thanks for the pointer! I hadn't thought about either (S)Cons or Aegis in quite awhile; it's good to be reminded. I will definitely spend some time reviewing the tests that come with SCons, and try using it for some of my projects. Nothing like build scripts in python to make you appreciate how painful make files can be ;)

      It's been interesting how most of the examples people have come up with are Java and Python; seems to be a language culture kind of thing.

      Thanks again.
    • By the way, Scons, as Python, is cross-platform. But Aegis is not: AFAIK it's only for systems with Unix-like file permissions and all other ports are too unstable. So, here is my quastion:

      Have you ever consider Subversion instead of Aegis for change management in Scons? If so, does it has same level of support for testing? If so, can you recommend a combination of Subversion+Scons for the process automation in mid-size teams?

  • Boost (Score:3, Informative)

    by Screaming Lunatic ( 526975 ) on Friday February 13, 2004 @12:49AM (#8266667) Homepage
    The best example that I know of. Every library is tested and thoroughly review. There are regression tests for every significant C++ compiler out there. http://boost.sourceforge.net/regression-logs/

    And check out the Boost unit test libraries. http://boost.org/libs/test/doc/index.html

  • Looking for an example of Test-Driven Development? (Score:3, Informative)

    by Anonymous Coward on Friday February 13, 2004 @01:08AM (#8266766)
    Try the book called "Test Driven Development: By Example" by Kent Beck!

    It's a neat little book. The first third demonstrates writing a Money class in Java using test-driven development. It's kinda like you're sitting next to him and he is demonstrating. In that example he shows a lot of what comes up in an average TDD session. If you're new to it, you might not realize how fluid it is, and how tiny the steps can be. Even if you *think* you know what TDD is about from reading a description, this will really show you how it works.

    Then the next chapter is really cool.. here he writes a unit test framework in Python .. using the framework he is writing to write the framework! Here he shows you how to bootstrap a new testing framework, which you probably won't ever need to do, but it was cool. He starts with a single test that prints "1" or "0" on the screen for pass/fail, and builds on that.

    Final third of the book is patterns, example, theory, philosphy, somewhat interesting.

    This is a book you'll only read once or twice, honestly, but you will benefit greatly from it. In my opinion.

  • The Craftsman (Score:3, Informative)

    by Anml4ixoye ( 264762 ) on Friday February 13, 2004 @10:15AM (#8268811) Homepage

    Software Development Magazine [sdmagazine.com] has been running a series for about the past year called The Craftsman written by Robert C. Martin. It focuses on a young apprentice writing a java app with his mentors. Nothing is done that doesn't involve a test first.

    While the series itself is kind of slow, it is a good introduction to TDD, and I really enjoy Robert's writing style. Might be able to lead you to some more examples.

  • OSS are unlikely to use XP or other agile development systems.

    Therefore most test first projects are probably closed source. I can't show you our whole code base but we are a TestFirst XP place with 1654 unit tests currently in place.

    For large scale testing mock objects are invaluable. See www.mockobjects.com and www.mockmaker.org

    Here is an example of what a test looks like using Junit and MockObject testing. It might give you a feel for how easy the tests are to write.

    public void testBlowWholeCache()

    • Here is the setup method for that test suite. Just in case you wonder how all the objects are hooked up.

      public void setUp() {
      myMockResinApplicationAdmin = new MockResinApplicationAdmin();
      myMockResponse = new MockHttpServletResponse();
      myMockRequest = new MockHttpServletRequest();
      myMockServletOutputStream = new MockServletOutputStream();
      myMockResponse.setupOutputStream(myMockServletOutp utStream);
      myServlet = new ResinCacheManager(myMockResinApplicationAdmin);
      }

  • gcc (Score:3, Informative)

    by IainHere ( 536270 ) on Friday February 13, 2004 @10:55AM (#8269138)
    It's not *exactly* test driven, but gcc has a very extensive test suite, and adds regression tests for every new bug that is uncovered. The project certainly passes your 50kloc specification!

    http://gcc.gnu.org/install/test.html
  • I am very curious about TDD and would like to get in deeper, but all of the tutorials that I have seen are writing OO type applications. How would you make use of TDD if you were writing web applications using ASP/VBScript or PHP? Is it possible.

    Thanks in advance for your replies.
  • Besides being an excellent development environment with support for XP (unit testing, refactoring, etc), it's developed with Unit testing galore. See http://www.eclipse.org and look at the downloads section. There are source downloads as well as complete tests. Excellent examples of Java development with patterns, testing, and refactoring.
  • And the TDD book by Kent Beck shows how the evolution of an application can be driven by unit tests.
    Fwiw - I'd suggest that a large project is _not_ the best way to get to understand how unit testing works - there is likely to be way more detail than you need or want. Matt Raible [raibledesigns.com] shares some code (esp. AppFuse) which includes unit tests, and describes them in his wiki on Appfuse tutorials [raibledesigns.com].
    His "Struts Resume" demo application contains some pretty interesting unit tests of a real-world application.
    Now, here's

Slashdot Top Deals

With your bare hands?!?

Close