Comments on: How Do You Start TDD? http://www.symphonious.net/2006/08/27/how-do-you-start-tdd/ Living in a state of accord. Sat, 10 Jan 2009 00:06:01 +0000 http://wordpress.org/?v=2.7 hourly 1 By: Steve Loughran http://www.symphonious.net/2006/08/27/how-do-you-start-tdd/comment-page-1/#comment-30169 Steve Loughran Sun, 27 Aug 2006 16:56:31 +0000 http://www.symphonious.net/2006/08/27/how-do-you-start-tdd/#comment-30169 If you develop bottom up, start at the bottom: 1. start on the libraries; write tests for new libs that you add. 2. write tests to check your understanding of new APIs; if you are learning jdbc, tcp, whatever, write tests to check your assumptions. These turn out to be handy regressions in future. 3. For web-based apps, jump to HttpUnit for functional testing of the app. 4. Swing? There is a swing junit extension, but all such guis are hard to test. Its a side effect of system integration and the complexity of the app. How do you test that drag and drop and resize works? On every single platform? That's why web based apps are so appealing -you only need to test in a limited set of browsers and you are done. The other thing to remember is this: a good test breaks the app. There's little point wasting the time writing a test if you provide sample data you know will work. That's not a test, its a demo, and while useful (you need at least one correct path to test), most tests should be designed to break the app. If you develop bottom up, start at the bottom:

1. start on the libraries; write tests for new libs that you add.

2. write tests to check your understanding of new APIs; if you are learning jdbc, tcp, whatever, write tests to check your assumptions. These turn out to be handy regressions in future.

3. For web-based apps, jump to HttpUnit for functional testing of the app.

4. Swing? There is a swing junit extension, but all such guis are hard to test. Its a side effect of system integration and the complexity of the app. How do you test that drag and drop and resize works? On every single platform? That’s why web based apps are so appealing -you only need to test in a limited set of browsers and you are done.

The other thing to remember is this: a good test breaks the app. There’s little point wasting the time writing a test if you provide sample data you know will work. That’s not a test, its a demo, and while useful (you need at least one correct path to test), most tests should be designed to break the app.

]]> By: George Dinwiddie http://www.symphonious.net/2006/08/27/how-do-you-start-tdd/comment-page-1/#comment-30124 George Dinwiddie Sun, 27 Aug 2006 04:10:13 +0000 http://www.symphonious.net/2006/08/27/how-do-you-start-tdd/#comment-30124 My advice is *not* to start with a test for main(), or swing, or struts, or rails, or whatever. Start with what you want your app to *do*. The framework, whether console-based or GUI, can be added onto that, later. (And can be mostly test driven, though many people skip that.) Think about the primary function of the application, and write a test for a rediculously simple case. Use this to drive an the creation of a top-level business class which just fakes the expected return. As you add tests, use them to drive the creation of the end-to-end system, faking the return of new collaborators, if needed. You can then add tests for those collaborators to flesh out their requirements. Once you get started, it gets easier, even if you started in the wrong direction and need to rip out some of your early work. My advice is *not* to start with a test for main(), or swing, or struts, or rails, or whatever. Start with what you want your app to *do*. The framework, whether console-based or GUI, can be added onto that, later. (And can be mostly test driven, though many people skip that.) Think about the primary function of the application, and write a test for a rediculously simple case. Use this to drive an the creation of a top-level business class which just fakes the expected return. As you add tests, use them to drive the creation of the end-to-end system, faking the return of new collaborators, if needed. You can then add tests for those collaborators to flesh out their requirements. Once you get started, it gets easier, even if you started in the wrong direction and need to rip out some of your early work.

]]>