UI Unit testing in combination with SbE

[ed Bruin]

Dear group,

We have been using specification for example for quite some time now. We use it in a Front End environment. I know SbE is much more powerfull on a layer where the actual business logic is build, but   this is unfortunately quite hard in the big organisation. It's simply a bridge to far fro now. So what I advice is to limit the specs to focus on the UI and if business logic has impact on the UI then we will test this.

The discussion we have now with developers is that they don't see the advantage of SbE and automation on the UI. The developers are already using jasmine for unit testing (not using SbE, hard to read for the business) and the addition of automating the actual specs doesn't seem to get the developers enthusiastic. Jasmine tests are not using API services. Automation of the specs is done using Twist where we test E2E. What happends now is that testers mostly create the automation code for this E2E tests and devs are creating the jasmine tests. There is no 'whole team approach' for the autmation part of SbE (SbE workshops setting up examples and all are working great btw). What I also see happening is that extensive field validations or tab sequences are being automated in Twist. In my opinion this should be done in Jasmine.

What I like to know is: 

- What is your experience on automating specs on the UI in combination with unit testing the UI?

- What is the advantage for devs to automate specs when they already have jasmine?

- Where do you draw the line between jasmine tests and the E2E tests on a UI level? (Taken Mike Cohn's automation pyramid in account we absolutely want jasmine to test a lot of unit and technical stuff, but this doesn't mean the E2E stuff can't be led out)

Hope we can have a nice discussion on this topic :)

[Dmitry Zhariy]

Dear ed,

Specification by Example is just a tool that may help you to create right software. And it is mostly collaboration tool. It may not fit to your process and your team, and that’s OK.

If your team don’t see the advantages of Sbe, maybe they just don’t have “shared understanding”?  Of course, if you were on the SbE workshop and the rest of your team – not,  where this “shared understanding” can come from? :D

SbE is not about automation, it’s about communication. If your team have enough communication to develop right software – than you don’t need to change anything.

You wrote:  “using jasmine for unit testing (not using SbE, hard to read for the business)”.

Is that really a problem that business cannot read the tests? Would the “business” read the tests if they become more readable?

If you cannot sell SbE to your team all together, try to split it on separate techniques and sell one by one.

As the first step, you could write some tests (key examples) and share (discuss) those tests with the developers (3 Amigos). It should not be “The comprehensive specification”, it should be “Hey guys, that’s how I am planning test that!”.

The next step is changing the language of the “specifications” from English to Gherkin.

The testers can start using Gherkin to describe the bugs in the bug tracker.  So everybody will be forced to be familiar with Gherkin.

Then you can say, “hey guys, this bug seems to be a missed requirement, let’s automate it!”.

About your question on Specifications for UI. Each UI action has some behavior under the hood.

You can say:

When I press button with text “1”

And press button with text “+”

And press button with text “1”

And press button with text “=”

Then the text box “R” should have value “2”

 

Or you can say:

When I sum two numbers: 1 + 1

Then the Result should be 2

If you need to implement a simple validation for required fields or max field length – forget about BDD/Sbe. Just write a test. 

You are right -- it would be  better to write such test with jasmine, but twist is also acceptable.  Does it work? Is it useful?

If yes – than it is acceptable.

Hope it will help 

~ Dmitry