On 19 Jul 2013, at 19:53, Paul Robinson <[email protected]> wrote: > On 18 Jul 2013, at 11:06, Graham Ashton <[email protected]> wrote: > >> the Ruby community's repeated failure to understand the purpose of testing, >> and the consequent obsession with finding more ways to decrease our ability >> to save/make money for the organisations we work for.
> The best way to convince the Ruby community of doing something differently is > with code. Always has been, always will be. Hmmm, I can see that code can be a persuasive way to get new ideas across. Sometimes though, you want to advocate is a move away from a current practice. How do you go about doing that? What strikes me about the Ruby community is that we're a very fashion-lead bunch. It seems as though new projects get adopted simply because they're there and they look cool, not because they're better (in a business context) than what came before. Sometimes they're worse, but the Ruby community adopts them as a new default anyway. We don't seem to be very discerning. We lack taste. > DHH showed his opinions by producing the first cut of Rails [snip]. And > Cucumber, RSpec, etc., etc.... So... Cucumber and RSpec are the two best examples of the stuff that bothers me. Pause reading this for a moment and ask yourself why you write tests. For most Rails apps all the answers we can come up with can be rephrased as: "We write tests to minimise the cost to the business/organisation/client incurred while developing, maintaining and operating the app." If you're writing tests for a reason that can't be reduced to "saving/making money", I'd love to hear about it. That covers the time taken to write the code, the time spent changing it, and the money that might be lost if something went wrong that could feasibly have been caught by an altnerative testing strategy. It's the best criteria I know for evaluating testing practices, and it ought to be context (i.e. application) specific. But back to my point. Cucumber is the most expensive (to use, in actual pounds) testing framework I've seen since Fitnesse. It doesn't do anything that can't be done more cheaply test-unit. Not a thing. Happily almost nobody needed to use Fitnesse, but when it was used it was by teams that actually needed it. I've never come across a team that really needs the overhead of Cucumber (I've still not met a product manager who gets excited about reading the scenarios, though I've spoken to a few who've been brainwashed into thinking they should). RSpec adds zero business value over and above test-unit, yet comes with an obtuse API that developers have to waste their time learning. I wouldn't mind so much if the RSpec API provided something more useful than an alternative to basic Ruby, or produced something that communicated as much of what my test was doing as basic Ruby can. It fails on both counts. Time spent learning about changes to a tool like RSpec is time that could be spent shipping products. And then the RSpec API changes for no useful reason, and more time is wasted learning this release's minor changes (not just by you, but by *everybody* who ever works on the app). I'd love to get Rails developers to consider the possibility that they're pissing cash up the wall by: - Writing far too many tests (I see this everywhere) - Writing their tests in RSpec and Cucumber - Writing assertions that are too brittle I reckon we could save (globally) millions of dollars in lost resource per annum if we changed the Rails community's approach to testing. It needs education and good judgement, not a new project. > I'd argue you could do (or convince somebody else to do), something similar: > build a framework where doing the right things based on those ideas is > easier. Interesting idea, but I can't see how to apply it here... -- You received this message because you are subscribed to the Google Groups "NWRUG" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nwrug-members. For more options, visit https://groups.google.com/groups/opt_out.
