On Sep 16, 2008, at 4:11 PM, Brice Figureau wrote: > [...] > OK, that's easier than what I first thought. I'll spread the tests in > different unit tests. > Hopefully that'll start a parser test (or you want a different > patch?), > that we can later on increase with more tests.
I'm fine with the different sets of tests being in one patch -- they're all adding the same piece of functionality, after all. >> I'd include them if they were available, yeah, so go ahead and do >> them, as long as you're doing tests at the same time. > > Unfortunately, I'm pretty old school regarding programming (too much > time in this business I guess :-P ), so I still don't have the > reflex to > start by the test part before the code part, so I always feel > implementing the test _after_ the code is a duplicated effort :-( > I guess it's time to change how I see things :-) and start to really > embrace test driven development. Just to be clear, I really just meant as long as the patches had tests; I don't particularly care whether the tests or code were written first. I will say, though, I've just recently felt like a good portion of my development makes more sense when done test first. For this kind of thing, it can often actually be much easier to do test-first, because you describe the new behaviours you're adding: describe "lexer" do it "should have an append token" end describe "scope" do it "should be able to append to variables in a subscope" end describe "parser" do it "should correctly parse variable append statements" end Then you just have to decide what success means for that test. For me, whether I do test-first or code-first is usually a question of how clear the design is in my head. I seem to be able to design better from the code, but then once I have the design fixed in my head, I usually toss the code I have and restart with test-first development. The last year, while outwardly not all that productive in terms of what I've done on Puppet, has been a huge learning experience for me in terms of how to do test-driven, and behaviour-driven, development, along with what it means to actually write both good tests and testable code. As I go back through older code, I see that I've not just written poor tests, I've written code that's actually hard to test, which is a real shame. -- Someday I want to be rich. Some people get so rich they lose all respect for humanity. That's how rich I want to be. --Rita Rudner --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet 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/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
