Well, except that you should apply your rule to unit tests, too. I'm not sure why you'd put in weeks of development on a quad tree, and not write tests for it. But if there's a question about whether you want to be spending weeks of development on a quadtree implementation, a simple implementation and a unit test to drive it and measure its memory usage and performance would seem like a wise precaution to me.
But really, weeks of effort on a quad tree? Or even a K-D tree? That doesn't quite make sense to me. I'd guess it was a quad tree, and a lot of functionality built around the quad tree? I wouldn't commit more testing effort than I would coding effort. Write a unit test for what you're about to write. NOT for an entire API! Test-first programming does NOT mean you write all your tests before you start coding. That's not at all agile, and you're quite right to reject it. But that's not what's meant by "test-first programming". And my experience is, done right it saves a lot of debugging time. On Apr 21, 1:18 pm, Warren <[email protected]> wrote: > Writing unit tests first to define exactly how a program will work is > nice if you have the luxury of knowing exactly how the program will > work ahead of time! > > I often have a general structure for a program (game) but I don't have > all the little details figured out because things don't always go as > planned. What if I write all my tests for a quadtree data structure > and put in weeks of development only to find out that the quadtree is > not fast enough or eats too much memory? > > Instead, I take the approach of working on the features that commit me > the least to a certain way of doing things. And I only write parts of > an application when I need them, not before. This eliminates much of > the waste that happens when you do an about face in terms of the way > your app works. > > Front loaded unit testing violates my rule, so I don't do it. > > On Apr 21, 2:27 pm, Matt Kanninen <[email protected]> wrote: > > > > > > > I find that most of my problems are device or user specific issues. > > So to be useful, the unit tests would have to run on the actual > > hardware used by consumers, and would have to emulate the behavior of > > real users. > > > Years ago, when I had to write a small bit of generic java code for > > server side logging, reporting, and metrics, that was going to be used > > for lots of different purposes, we used test driven development, and I > > was glad for the experience. > > > So basically, I suggest you use the right tool to ensure the right > > level of quality for each specific project. > > > On Mar 11, 1:36 pm, DulcetTone <[email protected]> wrote: > > > > I routinely find a disproportionate number of my bugs and crashes > > > reside in the code set up for the purpose of testing and evaluation of > > > the program rather in the function of the program itself. > > > > I'm sure this is a measure of my unfamiliarity with "best practices", > > > but I find it more beneficial to try to write crash-detection-and- > > > reporting code rather than explore testing. That said, I am not > > > inspired to look at junit.org > > > > tone > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group > > athttp://groups.google.com/group/android-developers?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group > athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
