1
votes

I'm using SpecFlow in order to BDD my application. I would like to iterate test, while each iteration repeats the previous parameters assigned.

Since this step should executed around 120 times I don't want to rewrite same test with different parameters.

Is it possible to iterate scenario parts only?

The real scenario:

I have application function which opens file and close it.

I would like to open and close files until the application fails.

The last test suite I made (using pure C# code) Memory leaks in the application under test were found causing failures at the 10th iteration, still after debugging the application under test it fails at the 50+ iterations(again due to memory leaks).

I would like to use spec flow to test this scenario.

For logging reasons I would like to split each iteration to different scenario. so instead of writing feature file contains many sub scenarios, is there a way to tell SpecFlow to iterate in ascending repeat sequence?

The scenario:

Scenario Outline: Open and close fileTestScenario1
Given Ready for input
When Open file <file_name>
Then File content is visible

Examples:
    | file_name | 
    | param1   | 
    | param2   | 
    | param3   | 

So I would like SpecFlow to generate the following tests:

  1. invoke scenario with param1 (Invoke with param1 and assert)
  2. invoke scenario with param1 and param2 (Invoke with param1 and assert then invoke with param2 and assert)
  3. invoke scenario with param1 and param2 and param3(Invoke with param1 and assert then invoke with param2 and assert then invoke with param3 and assert)
  4. ...

I know that scenario is atomic test unit, but still, if I want to perform this task - how can it done?

1
Maybe you could elaborate on your problem a little more. I'm not sure if I'm getting your problem right. But of what I think your problem is, it can't be done using SpecFlow. Because the functionality you're looking for is pretty straight forward and not that complicated, I think the easiest way is to just code it in your code behind your 'When I Login as <user>'. - TimothyHeyden
@TimothyHeyden The example above simplifies the problem. I would like to iterate step with different parameters over and over again and don't to duplicate my code - Saturn Technologies
This seems like a very strange requirement. If I read it right, you want: Test 1 = Action A, Assertion a; Test 2 = Action A, Assertion a, Action B, Assertion b; Test 3 = Test 2 + Action C, Assertion c. Why do you want this? Are you trying to find out where in a sequence of steps a failure occurs? Can you use more "real-world" type examples and explain why you need this kind of assertion/test-run pattern? - perfectionist
"in the last test I made (using pure C# code) I had failures at the 10th iteration caused due to memory leak."-As you have identified a memory leak issue using unit tests, I would continue to use unit tests to fix this issue. Also SpecFlow tests should be unambiguous and express expected input and output. "Then Test passes" is too ambiguous, replace this with something like "Then I can see the file content" or something similar. Also the "Examples" should record what a user should expect, having the code amalgamate the results in the "Examples" block will be very confusing to a reader. - Ben Smith
@Fresh I accept your comment - but unless I explain the entire logic of the application under test and the tests, my requirements might be unclear. But I do not look for work around or suggestions to solve this issue in technical way, simply want to know is it possible to iterate parts of scenario using SpecFlow? - Saturn Technologies

1 Answers

0
votes

What if you simply phrase your test as

Scenario Outline: Open and close fileTestScenario1
Given Ready for input
When Open file <file_name>
Then File content is visible

Examples:
| file_name | 
| param1    | 
| param1,param2   | 
| param1,param2,param3   | 

With the binding

[When("Open file (\w+)"]
public void WhenOpenFiles(string names)
{
  foreach(var name in string.Split(',', names)
  {
       OpenFile(name);
  }
}

However this method (known as exhautive testing) isn't the best way to approach your testing. All you've really done in this case in run a large number of tests in the hope of hitting an issue. At least reduce the tests so that instead of running with 1 file, then 2 files, then 3 etc., instead jump straight to 50 files as this handles the simpler cases too. You should also be using this approach to simply diagnose what the real problem is and then write a targeted test that takes you straight to that problem.

For example I came across an existing test today that was failing, and it was failing simply because it was Monday, i.e. it had some date logic which would only ever fail during an overlap in some TimeSpans that occurred on Mondays. However I proved this by writing a exhaustive test,

Foreach(var day in new[] { DayOfWeek.Monday, DayOfWeek.Tuesday, ....}
   Foreach(var hour in Enumerable.Range(0, 24)
     Console.Writeline(test(day, hour));

And then I deleted the exhaustive approach test because I could replace it with a single test only for Monday 10am.

Hope this helps.