Shane Mingins <[EMAIL PROTECTED]> writes: > On 25/11/2008, at 7:29 AM, Pat Maddox wrote: >> >> Lately I've been putting more and more stuff into ATs. I'm finding it >> valuable to keep tests for domain logic separate from plain ol unit >> tests...meaning that my Account object may be tested mostly with >> Cucumber, but helper objects such as a stats aggregator will be spec'd >> with code-level examples. >> >> Pat >> _______________________________________________ > > Just wondering a bit on this ... the bit about your Account object > being tested mostly through Cucumber vs unit tests. > > In my mind (as I think about this) cucumber is more about testing than > rspec is, meaning Acceptance Tests are more about testing where unit > tests when using TDD is more about design than testing. Do I make > sense? Email is not the best medium for conversations :- ) > > Now from what I have read of your writings I am assuming that you are > using TDD .... and so just from what I read above I am wondering if > that statement is true because TDD is driving the implementation of > Account, and so you will have a 100% coverage of the Account class > behaviour, but when it comes to testing, the AT is doing more of that > (meaning testing). Is that it? IIRC, in Kent Beck's TDD book there > is the example of TDD'ing a triangle (or something), but it was > something that showed that to TDD the triangle you ended up with less > tests than if you were testing the triangle. > > How's that sound? > > Cheers > Shane > _______________________________________________ > rspec-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rspec-users
Here's my latest Theory of Testing, in a nutshell: Logic in a system falls into one of two categories, business logic and supporting (infrastructural?) logic. Business logic is often then further subdivided into domain logic and application logic. Domain logic is the logic essential to the domain being used and would remain consistent between applications, whereas app logic is unique to each application. Most domain models I've seen used in Rails apps are used *only* in that Rails app, and tend to be simple enough, that this distinction doesn't matter a whole deal. Well, actually I think Rails devs just don't think in those terms, but whatever. It's this business logic that is important to capture in acceptance tests, in my opinion. We can write ATs for domain logic, as with the example I gave for the ATM withdrawal. And we can also write ATs for application logic, which is stuff like showing a success message on a page, or sending off an email, or whatever. I think some of the confusion comes from "edge case" having a pretty particular meaning to developers, but in the example I gave there's a lot of overlap between an important business scenario and a programmer's edge case. I'm finding that when that occurs, and I can be confident in my code after writing acceptance tests to cover the business scenarios, I don't need to write object examples. Then there are a bunch of objects that provide neither domain nor application logic - they're basically just the result of refactoring to keep your design clean. These are the objects I write examples for. They don't matter to the customer, but it is important to me that they work and are well-designed. And actually, I'm starting to relax on those a bit as well sometimes...Yehuda advocates a style that is basically JUST acceptance testing (though at various levels, because sometimes the "customer" is a business user and sometimes it's another programmer using your API). While I don't go as far as he does, I am less strict about directly testing every single method of every single object than I was just a few months ago. Wow, if that's it in a nutshell... :) Pat _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
