Hey all,
I suppose this is more of an opinion than right / wrong. But I was wondering how you develop - I personally have tried coding before testing as well as test-driven development, and realized how much nicer test-driven development is, if you can hold your horses.
But what I'm wondering is how do you develop? Also where does documentation fit into your picture?
Thanks for your help SO!
Matt Mueller
Personally, I prefer Behavior Driven Development. This is what I call TDD done right. Using BDD i don't have to think what to test, I just have to think of right questions to ask working with stakeholder. In this case stories stands for documentation, if one is working on large-enough module, some additional documentation might be needed as well.
However, I am not sure if this approach would fit nicely to enterprise-scale projects as this is what I do aside from my day to day job. My company prefers high-upfront architecture, so one is required to write documentation first, then do the coding and finally write unit test (if any). Probably there are also some teams which use TDD, but personally I wasn't involved in such project yet. Oh, well...
1) Requirements: In a perfect world we'd start with all requirements documented. In reality we get as many of them down as possible until we feel that the risk of starting work is low enough.
2) Design: The goals of this documentation is to 1) be able to communicate with the team (assuming you have a team) 2) work through the design in your head in order to cut down on the amount of picking the first design that comes to mind instead of thinking through the options and 3) documenting why you made the design choices so that when the application is being maintained the maintainer can have a better understanding of why design choices were made. For most systems and organizations, documentation of every class, method, and property is a waste of time because it will not be maintained. But design choices don't need to be updated as often. This also requires a design peer review.
3) Decide how to tell when you are done with development. In other words, what and how are you going to test. This should require a peer review.
4) Code. A peer review at this stage is mainly for cross-training between new/old devs, help ensure you are following coding standards, and possible performance improvements. If you find a logic problem here you either are not testing enough or you have a bug in your test.