Field validations - Unit tests?

[192...@gmail.com]

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

[Eric Kessler]

On Sunday, February 18, 2018 at 5:38:21 PM UTC-5, matthew thomas wrote:

Hi

Hello!

 

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.

 

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.

 

Thanks

Matt

Enjoy,

Eric 

[matthew thomas]

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.