3 ms·

There is this odd trend amongst testing framework developers to make their frameworks more verbose, as if this somehow delivers value. Spek seems to be in this

There is this odd trend amongst testing framework developers to make their frameworks more verbose, as if this somehow delivers value. Spek seems to be in this tradition. Almost every other area of programming aims towards getting as much work done with as a little verbiage as possible. Why do testing framework people feel that programs should read like written prose? This idea has failed a great many times over the years. The ScalaCheck [0] library is actually innovating in the domain of testing. It's derived from QuickCheck, a Haskell library, and I believe an Erlang derivative is making $$s as a commercial product. [0]: https://github.com/rickynils/scalacheck https://github.com/rickynils/scalacheck

ams6110 13y ago
There's this idea that tests can be written by non-programmers (QA, business SMEs, etc.) which may be the motivator for this. Just a guess. I used a framework called FitNesse which was awful but which was built around this idea that tests could all be specified in spreadsheets and managed by non-technical folks.
- hhariri 13y ago
  I'd hope not. I think developers should write tests. And I think things like BDD is more about communication than anything else. The difference is however in using a language that is ubiquitous and understood by all parties, leaving ambiguity out. It is about contrasting what you've understood in terms of the requirement with what is expressed in the code.
davidw 13y ago
The Erlang one is this: http://www.quviq.com/index.html http://www.quviq.com/index.html
kodablah 13y ago
Why do you believe it has failed many times? It seems a more literate programming style is becoming more and more common. I find that features such as those written in a Gherkin format serve other developers very well as to what is expected of the system. I use it as documentation quite often.
hhariri 13y ago
I think there needs to be a distinction between verbosity and clarity. For me code that is clear with precise wording of methods and functions is important, even if these need to be more verbose. Amount of boiler-plate code on the hand is undesired. In terms of testing, I think defining the requirements inline with the tests that are meant to implement those requirements provides value, removes ambiguity and is easier for those coming to a new code base (or coming back to one).
astral303 13y ago
It does deliver value because it allows you to document the context of the assertion code in a way that's more enduring than a comment, and in a way that's visible at failure time. I actually use a homebrewed assertion context specifier, where I wrap blocks of code in a "that" context, which then decorates any thrown exceptions. When your tests grow past verifying that string concatenation of your string class works (short, sweet, tight unit tests), and you end up testing business logic, you end up with tests that are just not that short and assertions which are not single-minded assertion. Often times you end up writing multiple asserts for one logical "assertion result", e.g. assert that returned map not null, map contains expected key, value for the key has correct detail, etc. Providing a single intent reason for a group of assertions is very helpful. Sometimes when time is tight, you might end up extending an existing test to assert one more concept instead of breaking it up into two separate tests. Now you can provide separate context for that assertion, and having the code be in a separate closure/block helps isolate it too. Note, that this is altogether different than the concept of writing tests by non-programmers (e.g. Cucumber).

ams6110 13y ago

There's this idea that tests can be written by non-programmers (QA, business SMEs, etc.) which may be the motivator for this. Just a guess. I used a framework called FitNesse which was awful but which was built around this idea that tests could all be specified in spreadsheets and managed by non-technical folks.

hhariri 13y ago
I'd hope not. I think developers should write tests. And I think things like BDD is more about communication than anything else. The difference is however in using a language that is ubiquitous and understood by all parties, leaving ambiguity out. It is about contrasting what you've understood in terms of the requirement with what is expressed in the code.

davidw 13y ago

The Erlang one is this: http://www.quviq.com/index.html http://www.quviq.com/index.html

kodablah 13y ago

Why do you believe it has failed many times? It seems a more literate programming style is becoming more and more common. I find that features such as those written in a Gherkin format serve other developers very well as to what is expected of the system. I use it as documentation quite often.

hhariri 13y ago

I think there needs to be a distinction between verbosity and clarity. For me code that is clear with precise wording of methods and functions is important, even if these need to be more verbose. Amount of boiler-plate code on the hand is undesired. In terms of testing, I think defining the requirements inline with the tests that are meant to implement those requirements provides value, removes ambiguity and is easier for those coming to a new code base (or coming back to one).

astral303 13y ago

It does deliver value because it allows you to document the context of the assertion code in a way that's more enduring than a comment, and in a way that's visible at failure time. I actually use a homebrewed assertion context specifier, where I wrap blocks of code in a "that" context, which then decorates any thrown exceptions. When your tests grow past verifying that string concatenation of your string class works (short, sweet, tight unit tests), and you end up testing business logic, you end up with tests that are just not that short and assertions which are not single-minded assertion. Often times you end up writing multiple asserts for one logical "assertion result", e.g. assert that returned map not null, map contains expected key, value for the key has correct detail, etc. Providing a single intent reason for a group of assertions is very helpful. Sometimes when time is tight, you might end up extending an existing test to assert one more concept instead of breaking it up into two separate tests. Now you can provide separate context for that assertion, and having the code be in a separate closure/block helps isolate it too. Note, that this is altogether different than the concept of writing tests by non-programmers (e.g. Cucumber).