On 19 July 2013 21:01, Graham Ashton <[email protected]> wrote: > 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. > > Cucumber is a tool for doing BDD. If you misuse it and try and write unit tests, or even declarative acceptance tests then, it is expensive, however if you learn to use effectively and appropriately, i.e. do BDD withit then you can dramatically reduce costs in lots of different ways.
Unfortunately it has a history of being misused and misunderstood, but then again we can say the same about rails, ruby etc.. > 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. > > > -- ------------------------ Andrew Premdas blog.andrew.premdas.org -- 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.
