3 ms·
I think that one problem has been with some people promoting TDD by saying to write "the simplest thing possible to get the unit test to pass". I've seen "Uncl
by scottlilly 12y ago
I think that one problem has been with some people promoting TDD by saying to write "the simplest thing possible to get the unit test to pass".
I've seen "Uncle Bob" do his bowling game demo, without using the expected classes for Game, Frame, etc. It's an interesting exercise, but would be a horrible way to write any large-scale business application. However, some people walk away from that with the idea that they should write quick "hacky" code, instead of doing any thinking about design.
When I write a program, I use my [constantly-evolving] set of "best practices", based on what I've experienced when writing other applications. Writing a factory method for object instantiation is not "the simplest thing possible", but I've seen it come in very handy at times, so that's what I'm doing in my projects now.
After all, aren't retrospectives, and modifying your process based on what you've learned during your project, one of the huge points of Agile - even though I've rarely seen them done, let alone done well.
- cageface 12y agoThis is a classic and hilarious series of posts on the foolhardiness of the TDD approach to software design: http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/ http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/ Personally I prefer Rich Hickey's "Hammock Driven Development": https://www.youtube.com/watch?v=f84n5oFoZBc https://www.youtube.com/watch?v=f84n5oFoZBc