Writing feature inputs in the tabular format has recently been very
helpful. However, there are some things that seem kind of funny when
writing. For example, let’s say we wanted to ensure that certain
requests resulted in the access denied page:
Given Joe is a staff member without the ‘admin’ privilege
When I GET /admin as Joe
Then I am notified that access was denied
The possible variables here based on step implementations are:
Given XXXX is a staff member without the ‘XXXX’ privilege
When I XXX XXXX as XXXX
Then I am notified that access was denied
This requires the More Examples to look like:
| name | privilege | request_method | path | name |
| Joe | admin | POST | /invoices | Joe |
| Joe | admin | PUT | /invoices/1 | Joe |
etc…
This isn’t that bad, but it’d be nice if we could specify only the
variable inputs that we care about – the privilege, the request
method and the path. As the scenario involves more steps you have to
grow your tabular data, unless I am missing how to do something (which
could be the case).
It also seems somewhat odd that the first example is the scenario
itself. It almost seems like the scenario should define the
placeholders and the More Examples section should define all the input
data sets. For example:
Given Joe is a staff member without the ‘$privilege$’ privilege
When I $request$ $path$ as Joe
Then I am notified that access was denied
Examples:
| privilege | request_method | path |
| admin | GET | /admin |
| admin | POST | /invoices |
| admin | PUT | /invoices/1 |
It would somewhat rely on using the $\w+$ pattern to denote what
should be replaced by the Examples input data set. I’m not tied to how
the inputs are grabbed, but it seems like moving in this direction
allows the tabular inputs to be more streamlined to what you wanted to
include in a scenario.
WDYT?
–
Zach D.
http://www.continuousthinking.com
http://www.mutuallyhuman.com
I’ve just updated it.