Skip to main content

How to deal with pauses and timeouts in specflow

So this blogpost is in response to the weekly Specflow blog posts and challenges that have been written by Gojko Adzic.

This weeks challenge was how would you rewrite or rephrase the below scenario:

Given a user registers successfully When the account page reloads And the user waits 2 seconds Then the account page displays "Account approved"

My initial though was something like this:

Given a user registers successfully
 When the account page reloads
  Then the account page is displayed within a satisfactory time period
    And the account page displays "Account Approved"

Now the problem with this scenario is what defines a satisfactory time? You could add it as a comment or in a scenario outline but over time the time a user waits could change and if this is updated in the code behind but the scenario outline or comments are not, then what the test does and what is described do not match - this would potentially cause issues in the future.

My next idea was to write it using examples:

Given a user registers successfully
 When the account page reloads
  Then the account page is displayed within <time> minutes
    And the account page displays <Account approval message>
Examples:
| time | Account approval message                                                      |
| 1      | Account Approved                                                                    |         
| 2      | Account Approved                                                                    |
| 3      | Account Not Approved - system took to long to respond      |
| 4      | Account Not Approved - system took to long to respond      |

Now this scenario although more detailed, suffers from the same problem as the original scenario i.e.  The timing can be affected by things like CPU usage and network traffic and you may get inconsistent test results. It does however, give the user different examples of what constitutes a pass or failure.

My final idea was this:

Given a user registers successfully 
 And the account page reloads
 When the account page loading progress bar is at 100%
  Then the account page displays "Account Approved"

Now this scenario (although not perfect) takes the timing element out and the reader of this takes away that the account page will display "Account Approved" once the progress bar is at 100% . It removes the actual time a user should be waiting  so it means that the code behind doesn't need to contain specific details about the time needed to wait just that once the progress bar is at 100% that the account page should display "Account Approved". This means that whatever the state of the CPU or network traffic the test will pass whether the progress bar takes 10 mins or 10 seconds to get to 100%.

I cant put my finger on why I still don't like my last scenario but I struggle with how you can successfully include waits and pauses in Specflow but  I'm sure Gojko will put me out of my misery ๐Ÿ˜€
















Comments

Popular posts from this blog

Building a test strategy for a new team

Teams, we have all been on them. Some are good and some are bad. Some we never wanted to leave and others we probably couldn't wait to leave. Now most of the time (well in my experience anyway) you tend to get put into a team that already exists. Maybe you are a new hire or maybe you have asked to change to a different product team.  When you do this, more than likely there will already be a testing strategy in place. It may be that you adapt it and change it in any way you see fit to improve the testing. But imagine if everyone on the team was new? How would you decide your testing strategy? This post will go through some useful things you can do to help a new team develop a test strategy. Table of Contents ๐Ÿ“ˆ What is a Test Strategy? ๐Ÿค” Where should I start? ๐ŸŽฏ Understand the company and their goals ๐Ÿ’ช Play to the teams strengths ๐Ÿ‘️‍๐Ÿ—จ️ Understand what quality looks like ๐Ÿ“ Understand Scope ๐Ÿงช Understand the type of tests you need ๐Ÿ“Š Measure your success ๐Ÿค Collaborate ๐Ÿ“ Summar

Developer and Tester Walkthroughs

In this blog post I am going to talk through a new technique that I have started where me, the tester, and the developer, have a walkthrough of a change that the developer has made for a particular feature. So what are these walkthroughs?  So these walkthroughs are a time for the developer and tester to get together and for the developer to talk through and explain the code changes that they have made. By talking through the code, I mean the actual code that the developer has written and not a demo of the new behaviour. During this session, the tester is free to ask any questions, this could range from questions about the code to questions about the effect that the code changes have on existing behaviour.  These sessions are time boxed to 30 minutes and typically take place before the developer has raised a pull request to merge the changes into the master branch. Why do we do them? In short - to find issues before I get a release.... but the 2 main reasons are based upon a co