How Do You Start TDD?
There's a lot of talk about how you convert a legacy project over to TDD, and there's a lot of talk about how you TDD on little code examples, but how do you get started on a real project? For a swing app, how do you TDD public static void main(String[] args)?
Atomic testing wants you to be able to mock out your dependencies, which leads to things like dependency injection. Somewhere along the line though, someone has to create those objects and pass them in. How do you atomically test that?
If I decide to use struts (or rails or whatever) as the base framework for a web-app, what tests should I have to ensure that struts is working as I think it should and to ensure that I know if something I've depended on changed in a future release?
I understand a whole lot about TDD and I'm quite comfortable sitting down with an existing code base and adding features via TDD. Despite that, every time I think about starting a new project and doing it right from the start, I just feel completely lost. I have no idea how I go about starting. Are there any good guides on starting a TDD code base? Are there any code bases out there that actual test everything that could possibly break or do they all have that one nasty bit of code that sets everything up and that we just can't test?
August 27th, 2006 at 2:10 pm
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.
August 28th, 2006 at 2:56 am
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.