> Wow. I have no idea what you said in this sentence. > > What I'm saying is simple: some Rails unit tests will always be broken if > they rely on consistent ordering when there is none (like with hashes).
Wow. You seem to bein a bit of an asshole here. Not sure how I've offended you, but apologies if I have. Perhaps the reason you don't have any idea what I'm saying is that unlike you, what I'm saying is *not* simple. I work on XP teams where TDD is our religion. No broken tests. Ever. A broken test and failing build is reason enough to stop the team working on anything else until the build is fixed. Whether it's a simple typo, an incorrect test, or broken code. What I'm trying to ascertain is whether thats true here. Irrespective of that particular test and that partiular fix. The volume of testing and attention to detail on the rails project makes me imagine it is true, and that a failing test (any failing test) would be bad juju. > Although it's not high priority (the codebase is not defected, just tests), > eventually they should get fixed (but not with the #7614 approach). You seem to suggest that it's not true, and that a few broken tests are low priority. That may be true, but I have to say that your apparent inability to understand the question and the distinction means I don't really hold your answer as particularly authoratative. > What I'm also saying is: don't sweat about it. Concentrate on the > realdefects (if there are any). And again I suggest that in the teams I work with, failing tests* are* real defects. You obviously disagree. Fair enough. Let's move on. Alan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
