[Cucumber] [Cukes] Organize your code according to tests in Gherkin
(too old to reply)
Michal Bystricky
2017-09-27 14:40:53 UTC
Hello everyone,

We would like to introduce you a new kind of modularization (which is
compatible with object-oriented modularization):

Test Driven Modularization

What is (use case and) test driven modularization?

The approach aims at organizing code according to use cases and tests, *e.g.
user acceptance tests with Cucumber*, and enforces them to be represented
in code. Both use case and test driven modularizations remain compatible
with each other while at the same time open new capabilities of having
different views on software based on use cases and various tests

All is ready at http://useion.com/en/index.html (examples, docs, tutorials,
tools, forum etc.)

What you get: Improved code comprehension and maintenance

Having use cases or tests right in code makes code more comprehensible. It
is enormous help for programmers and even more to other stakeholders who
come into touch with code. For example, try to understand what is program
doing from the object-oriented code
<https://github.com/opencart/opencart/tree/master/upload/catalog>, and try
to do it with the use case driven code
For us, it took approximately four hours to get familiar with the
object-oriented code, and only a few minutes with the use case driven code.
The system is free e-commerce platform OpenCart.

The code organization according to use cases and tests also helps with
location of changes. Relating a change to the corresponding place in
object-oriented code is difficult because code is organized according to
technical concerns, such as objects. But change requests are expressed in
terms of usage scenarios, e.g. where a bug is located in user interface, or
which changes and where they should be applied in user interface.
Therefore, to reflect changes flexibly, code should be organized according
to usage scenarios, i.e. use cases or user acceptance tests.

*In test driven development*, test driven modularization is particularly
suitable, because it reduces frequent switching between tests and code.
Developers have to switch between tests and code hundreds of times to make
their test "green". Although a test itself is contained within a small
number of mock modules, the tested code remains spread throughout many
modules, which significantly increases tracing. Having tests included with
the code they test makes the situation better.

What do you think?

We'd love to hear from you. Please, share your feedback.

Thank you,

All the best,

Posting rules: http://cukes.info/posting-rules.html
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.