Discussion:
[Cucumber] Field validations - Unit tests?
(too old to reply)
1***@gmail.com
2018-02-08 02:02:32 UTC
Permalink
Raw Message
Hi

I'm new on the Cucumber journey so I'm currently getting used to the
framework that comes with a delivery using Cucumber.

One thing I am feeling a little unsure on at the moment is UI field level
validations. The business have specific requirements for field validations
i.e. mandatory, field length, data types, date pickers don't show dates in
the past.

My initial thoughts are to get such checks implemented as unit tests.
Firstly I would like to see if my thinking that this sort of checking is
best done at Unit test level.

The other thing I am then thinking about is how I expose these rules to the
business. The business facing part is the feature file but field rule level
of detail would make them messy and boring to read. So where do people
expose these rules to the business and where do devs learn the rules to
implement?

Thanks
Matt
--
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.
Eric Kessler
2018-02-19 04:44:40 UTC
Permalink
Raw Message
Post by 1***@gmail.com
Hi
Hello!
Post by 1***@gmail.com
I'm new on the Cucumber journey so I'm currently getting used to the
framework that comes with a delivery using Cucumber.
One thing I am feeling a little unsure on at the moment is UI field level
validations. The business have specific requirements for field validations
i.e. mandatory, field length, data types, date pickers don't show dates in
the past.
My initial thoughts are to get such checks implemented as unit tests.
Firstly I would like to see if my thinking that this sort of checking is
best done at Unit test level.
Generally, yes. One end to end test is sufficient to prove that a given
field is being validated. After that, the many different ways to trigger
that validation can be handled by unit tests. Using logging in as an
example, I would write one GUI level test that tries to log in with valid
credentials and one GUI level test that tries to log in with bad
credentials. For all of the many variations on invalid credentials (too
short, bad characters, etc), I would have those be covered by unit tests
instead.
Post by 1***@gmail.com
The other thing I am then thinking about is how I expose these rules to
the business. The business facing part is the feature file but field rule
level of detail would make them messy and boring to read. So where do
people expose these rules to the business and where do devs learn the rules
to implement?
If the validation rules are relevant to the business, then they can live in
the feature files with the other tests. The difference is that inside of
the step definitions, instead of having code that will create a UI and
drive it, you would have code that instantiates whatever objects do the
validation and test them directly. If the Cucumber framework that you are
using is in the same language as the system, then this should be relatively
straightforward.

If the development and testing is done in two different languages, then you
can still use the same feature files but you may want to mark which tests
you are leaving unimplemented because they are covered by unit tests so
that Cucumber doesn't try to run them.
Post by 1***@gmail.com
Thanks
Matt
Enjoy,
Eric
--
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.
matthew thomas
2018-03-01 02:41:38 UTC
Permalink
Raw Message
Thanks Eric. I only just saw this reply. I thought my initial post went
missing as couldn't see it on the board.

All makes sense and I like the thinking of interacting with the build
methods directly rather than by a web driver. My test build is in a
different language to the solution but I may speak to the devs about any
ways we can make this work.
Post by Eric Kessler
Post by 1***@gmail.com
Hi
Hello!
Post by 1***@gmail.com
I'm new on the Cucumber journey so I'm currently getting used to the
framework that comes with a delivery using Cucumber.
One thing I am feeling a little unsure on at the moment is UI field level
validations. The business have specific requirements for field validations
i.e. mandatory, field length, data types, date pickers don't show dates in
the past.
My initial thoughts are to get such checks implemented as unit tests.
Firstly I would like to see if my thinking that this sort of checking is
best done at Unit test level.
Generally, yes. One end to end test is sufficient to prove that a given
field is being validated. After that, the many different ways to trigger
that validation can be handled by unit tests. Using logging in as an
example, I would write one GUI level test that tries to log in with valid
credentials and one GUI level test that tries to log in with bad
credentials. For all of the many variations on invalid credentials (too
short, bad characters, etc), I would have those be covered by unit tests
instead.
Post by 1***@gmail.com
The other thing I am then thinking about is how I expose these rules to
the business. The business facing part is the feature file but field rule
level of detail would make them messy and boring to read. So where do
people expose these rules to the business and where do devs learn the rules
to implement?
If the validation rules are relevant to the business, then they can live
in the feature files with the other tests. The difference is that inside of
the step definitions, instead of having code that will create a UI and
drive it, you would have code that instantiates whatever objects do the
validation and test them directly. If the Cucumber framework that you are
using is in the same language as the system, then this should be relatively
straightforward.
If the development and testing is done in two different languages, then
you can still use the same feature files but you may want to mark which
tests you are leaving unimplemented because they are covered by unit tests
so that Cucumber doesn't try to run them.
Post by 1***@gmail.com
Thanks
Matt
Enjoy,
Eric
--
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.
Loading...