I fully support this endeavor and will put in as much time as I can find. w00t.
-carl On Fri, Oct 24, 2008 at 4:44 PM, Dan Kubb (dkubb) <[EMAIL PROTECTED]>wrote: > > A few of us are working on rewriting DataMapper's specs and docs, and > I wanted to make the community aware in case anyone is interested in > helping out. > > After MerbCamp there were a number of attendees that expressed > interest in helping update DataMapper's specs and docs to a higher > level of quality. As with all open source project, the docs need a > bit of work, but the real problem is the specs that have grown up over > the last 6 months or so. > > The unit specs in particular use mocks almost exclusively, so that > even the smallest change to DM's internals would require changes to > the specs. When there's a tight coupling like this, and you're > changing specs for the smallest code change, then you're losing one of > the biggest benefits of specs: a fixed reference to compare against. > Because both change at the same time you could easily introduce a bug > in the specs AND the code, and you'd never know it. > > We decided to totally scrap all the specs in DM and start with a clean > slate. In a nutshell here is what we are doing now: We're looking at > each individual method, updating the docs to match what the method > *should* do, and then writing specs against those docs. In some cases > the methods do more, or do the wrong thing, so we mark those specs as > pending. Once we've specced the majority of the class and have > achieved 100% coverage (aside from the pending specs and dead code > paths) we're going back and refactoring the methods so the specs pass > and the coverage reports 100% coverage according to rcov. In certain > cases we're also simplifying complex code where appropriate. > > Also we are aware that rcov coverage is nearly meaningless, but it's > the best tool we have at the moment to at least ensure the specs are > exercising each line of code. We do plan to use heckle to torture the > specs after we've achieved decent coverage. > > The goal is to write specs for the entire public and semi-public API > in such a way that we will be able to refactor DM's internals without > breaking anything the end user and plugin authors rely on. There are > a number of improvements and optimizations we have planned are > hampered by the state of the specs. > > The last week or so that we've been working on this project has > already uncovered (and fixed) a few nasty bugs and simplified the code > considerably in the classes we've focused on. We've also discovered a > few assumptions that were incorrect and probably causing a handful of > the tickets in Lighthouse. I'm hoping to recruit a few more people to > help with the project now that we've got a pretty good understanding > of what we're doing. > > If you're interested in helping out, please do the following: > > 1) Read the overview document: http://github.com/dkubb/dm-core/wikis/home > 2) Join #dm-hacking on IRC and ping any of the people listed at the > bottom of the wiki page to see if they need assistance, or if you have > any questions. > 3) Checkout my fork at github.com/dkubb/dm-core and review the specs > to see the style we're using. In particular check out the shared > collection specs in spec/lib/collection_shared_spec.rb I've been > working on which are probably the furthest along so far. > 4) Add your name beside one of the unclaimed classes at the bottom of > the page once you understand what we're doing. > > Dan Kubb > (dkubb) > > > -- EPA Rating: 3000 Lines of Code / Gallon (of coffee) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" 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/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
