[TIP] running away from RSpec

[Phlip]

Alfredo Deza wrote:

> For the past few weeks I have been thinking a lot about RSpec and why there
> is no clear, definite answer when someone asks:

Because, frankly, it sucks. See below...

>  "I'm looking for a Python equivalent of RSpec. Where can I find such a
> thing?"

We tried RSpec at Integralnet, for several months, and it's a ton of
syntactic sugar around one tiny granule of salt.

In pseudo-code:

  setUp
      x = 42

      specs using x

      setUp
         y = 43

         specs using x and y

That's all there is to it - "subcontexts". The incredibly trivial feat
of nesting two setUp definitions so a test can use fixtures from both.

The rest is nothing but everted assertion syntax, and 'clever strings'
in place of stodgy_method_names. Oh, and every fixture and reusable
assertion you write for TestCase, you gotta write it again for RSpec,
because it uses a completely different framework.

You /could/ do all that in Python, even without too much self. clutter. But...

RSpec is incredibly over-represented in the Ruby space for a simple
reason - it presents the empty promise of Behavior Driven Development.

The _point_ of BDD is your civilian clients (your Onsite Customer) can
author test scenarios without worrying about _any_ programming syntax:

Scenario: Run one multiplechoice question through the system.

    Given a multiplechoice question FM_Color asking
             "What is your favorite color of fuzzy motorcycle?"

      And its answers are Teal, Puce, and Cyan
      And Puce is correct
      And user D42 answers Teal to question FM_Color
      And user D43 answers Puce to question FM_Color
      And user D44 answers Cyan to question FM_Color
      And user D45 answers Teal to question FM_Color

     When a manager requests a report on FM_Color
     Then the report contains Teal 2, Puce 1, and Cyan 1

      And the report's title is
              "What is your favorite color of fuzzy motorcycle?"

      And the Puce answer is correct

After I give a non-technical client a BDD scenario like that, they
will typically clone-and-modify it, or write their own, without any
prompting. You get the perfect intersection of business requirements
and technical specifications.

Those strings match regular expressions, so they can transparently
accommodate grammar (?:is|are), and can validate that 2, for example,
is a number and not characters.

In my Morelia system, the regular expressions are __doc__ strings on
step_() methods, embedded in NORMAL TestUnit test suites.

In other words, I did not invent a whole new unit test layer, just to
be able to put literate behavior scenarios on top. Here's some steps:

    def step_a_question_asking_(self, question_type, question_name, question):
        r'a (multiplechoice|rating) question (\w+) asking "([^"]+)"'

        self.question_type = question_type
        self.question_name = question_name
        self.question = question
        self.params = []

    def step_its_answers_are_(self, answers):
        r'its answers (?:is|are) (.*)'

        self.answers = split_and(answers)
        self.save_question()

(Note that I'd like to merge split_and(), not shown, and (.*), to
achieve better validation, if my regexp chops were up to it!)

> Ok, if that is so, then why there are so many projects (most of them already
> un-maintained) that try to give
> some RSpec features to Python?

Because (ahem) Python under-represents TDD and BDD, so there's no clear leader.

Also because many of those projects are ... "ambitious" (meaning
"cluttered"), and they would require the kind of community support
that Watir, Cucumber, and RSpec take for granted. The program author
can't do it all alone - only customers can drive Agile projects!

Here's my sauce:

http://c2.com/cgi/wiki?MoreliaViridis

It _appears_ unmaintained for a simple reason - since writing it 13
months ago, I have never stopped using it, and I have never needed to
add a feature to it. (If anyone has any suggestions, I have time
available these days to add some!)

> Isn't that how we came about UnitTesting? (e.g. "hey that's JUnit and seems
> good let's implement that in Python")

That was >10 years ago. >sigh<

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand