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) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
