On Apr 16, 2009, at 12:39 PM, Andrew White wrote: > Well, I'm guessing the thinking is that the current tests should cover > most of the changes.
Sure, but I see new code without tests in the commits. > The problem with that is that a lot of the > current tests are tied to implementation specifics which are obviously > in a state of flux at the moment so (re)writing a whole bunch of tests > is probably a bit premature so I'm willing to cut them so slack at the > moment. That's why I said 'changes to tests', you would expect application specific tests to be disabled or removed if they start failing (which they obviously aren't because lots of them fail right now). I would expect a rewrite to happen in a separate branch and be merged once it's done, in which case it would contain tests. I had the impression that this was what Yehuda was doing, but maybe I'm wrong. Even though I can't imagine doing a large refactor without backing it up with tests, I wouldn't mind their approach too much if they would let us know their plans. I obviously can't merge the Rails master branch with my own work right now because that would introduce too many test failures. > What we could do with is a decent set of specs that cover what's going > to be the public API separate from the current test suite which is > tightly coupled to the current codebase. We could also do with a test > application for integration testing. That would be great, but that would also be supplemental to unit tests. Manfred --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
