What I already know.
I went for an interview for an industrial placement at a software company that uses Extreme Erogramming with TDD for all of their software. Now, I'm a big fan of XP and this has proven hugely successful for this company so I paid attention to their processes.
- Write the test. Make sure you give it a name that describes what the test is for.
- Fail the test. This was really important, especially as the application starts to grow, because new tests won't always fail, but they should. If you skip this step you can end up wasting a lot of time trying to fix a problem that isn't there.
- Get the test to pass as quickly as possible. This is also very important because it stops you spending hours trying to implement the most ideal solution and losing scope of what you're trying to do. Literally just throw in whatever you can to get that test to pass.
- Refactor. Make it look nice, now is that time to maybe think about the ideal implementation, but not too much.
This approach gets a lot of criticism from people saying that it promotes bad design, or poorly written code. But the idea behind TDD is that you're focussing on a single problem at a time. So when you start, yeah you have a bunch of really inflexible code and virtually no design in place. But as the number of tests grows and likewise the application, better design falls right into place and you end up with a very robust piece of software.
Anyway, I'll see how I get on. It may be a bit naive of me to just be saying All my products will be TDD from now on but I'm going to give it a go and see how far I get.
No comments:
Post a Comment