3 ms·

Have you seen Cucumber? https://cucumber.io/docs https://cucumber.io/docs It's a system that attempts to enable specifications for a software product to be writ

Have you seen Cucumber? https://cucumber.io/docs https://cucumber.io/docs It's a system that attempts to enable specifications for a software product to be written in a way that can be parsed by an automated testing framework. In theory, you carefully say what you want the software to do in given scenarios, human developers understand the spec as-is, and automated tests can read and execute the spec as-is as a test. I have no professional experience with it because all the docs make it look like something I would run from: lots of in-code scaffolding and talking like a computer just to get the same job done. But maybe you'll like it.

rgoulter 7y ago
FWIW, the "specifications can be tested" is nothing magical. It binds statements of the Cucumber spec to snippets of code using regular expressions. (The effect is about the same as titles given to blocks of code in Ruby's RSpec). The "it's not code" part of Cucumber is that the test document is something that a non-programmer won't freak out at manipulating. (But a developer would still have to make sure the code snippets bind to the statements, so...). Still, I like it. I really like the suggested tactics discussed in Specification By Example https://gojko.net/books/specification-by-example/ https://gojko.net/books/specification-by-example/
hinkley 7y ago
I have found that test suites solve this problem about 98% of the time and are easier to teach people to debug. That last 2% is pretty damned awkward though. When you have 2 preconditions your tests go cartesian, you have to pick a dominant one. It's always a matter of one sucking less than the other, but that situation isn't stable. It tends to flip as bugs are identified or requirements shift. Thing is, if it's 3 concerns, and definitely by 4, you're probably due for a refactor anyway, instead of reaching for Cucumber or a similar tool.

rgoulter 7y ago

FWIW, the "specifications can be tested" is nothing magical. It binds statements of the Cucumber spec to snippets of code using regular expressions. (The effect is about the same as titles given to blocks of code in Ruby's RSpec). The "it's not code" part of Cucumber is that the test document is something that a non-programmer won't freak out at manipulating. (But a developer would still have to make sure the code snippets bind to the statements, so...). Still, I like it. I really like the suggested tactics discussed in Specification By Example https://gojko.net/books/specification-by-example/ https://gojko.net/books/specification-by-example/

hinkley 7y ago

I have found that test suites solve this problem about 98% of the time and are easier to teach people to debug. That last 2% is pretty damned awkward though. When you have 2 preconditions your tests go cartesian, you have to pick a dominant one. It's always a matter of one sucking less than the other, but that situation isn't stable. It tends to flip as bugs are identified or requirements shift. Thing is, if it's 3 concerns, and definitely by 4, you're probably due for a refactor anyway, instead of reaching for Cucumber or a similar tool.