Comment

Comment by IanCal

I kind of agree with this, but then I see the same tests I've seen elsewhere:

      Scenario: Editing the nickname of a credential does not change the version
        When the nickname is modified
        Then the edit version of the credential should not change
This looks like an awesome test. Simple, clear, anyone can read it. What's wrong? One of the following:

* It's based on timing and unreliable

* It stores state and the steps can't be reused.

You simply cannot put the line "Then the edit version of the credentials should not change" elsewhere because the step involves the previous state of the system. This step can only come after this step:

    Given a credential for a supported vendor
These tests all look like they're testing really nice general properties, but they aren't. They're almost always just checking little properties here and there, and rarely doing just what the step says. Which could be fine, but the language doesn't support any idea of specified dependencies. I cannot change a test without understanding the code behind it.

What you end up with is a big codebase based on regexes, with very heavy (non-specified) dependencies. You have to be extremely careful not to end up like this, although the tests look more complex afterwards (but you have re-usable steps).

I think there's a great place for a quickcheck & cucumber combination.

parent IanCal 13 years ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton