I used to create scenarios where in scenario name I explain what is scenario.
For example:
Scenario: When during context switch, context doesn't match and list of facts for delete are shown to user, facts should be deleted if user has selected them in the list.
But problem is that scenarios getting more and more complicated and scenario names longer and longer. Should I keep writing long names or do you have some better suggestion?
The scenario outlined in the question sounds highly coupled with the system. What is the behaviour you're specifying?
However, to roll with what you've got, I think this is just a language issue.
I Think personally I would just rename it to something like:
Scenario: Should be able to delete non-matching facts
It's more generic but still tells you what's going on when somebody reads the scenario (given the context of the feature and other associated scenarios).
At the end of the day, the length of the scenario name shouldn't matter - just as long as those involved in the development (think the 3 amigos, developer, tester and business stakeholder); all know what it means. But obviously, the easier it is for somebody else to understand, the better.
Well it sounds like you are repeating yourself.
The test below probably doesn't match up to what you mean. But pretend it does.
If your scenario looks like this:
Given the current context is Green
And the following list of facts for delete are selected
| Fact | Checkboxstate |
| A | checked |
| B | |
| C | checked |
| D | |
When I perform a context switch to Orange
Then the following facts should be deleted
| Fact |
| A |
| C |
And the following facts should not be deleted
| Fact |
| B |
| D |
Then the test is barely more complicated than the scenario title you suggested.
(if the test is much more complex than this, then that might be another problem)
Instead try and keep the feature and scenario titles brief and meaningful: e.g.
Feature: Context Switching
Scenario: New Context should be enabled
Scenario: Selected facts should be deleted
etc.
Related
Am writing a sceanarios to verify a card in mobile app in BDD. The card contains 7 elements in it and each has a value or a copy. These need to be verified with predefined values / calculated values. so wanted to know, can i write the Assertions for all the 7 elements in single scenario or split it with 2/3 ?
There are no much details, so I can't be specific with the answer. Let's say you are using Python client for Appium tests. In such case it would be nice to use some unit testing framework (it could be Python built-in unittest module).
I'll recommend you to verify each element in a separate test case. This approach will make your life easier - you'll get separate status for each element verification.
Speaking about "How many assertions can take place for a scenario" question - I believe it depends on tools your are using. With Python unittest you may have a lot of assertions in a single test case, but this is bad practise. Please read the following:
https://softwareengineering.stackexchange.com/questions/7823/is-it-ok-to-have-multiple-asserts-in-a-single-unit-test
If I knew what you were meaning by "card", this would be a help, but lets assume for this that it's a debit/credit card.
What we could do here, is simply have one assertion:
Scenario: Adding a new payment method
Given I have a card with the following details:
| Name | Mr Test McTestington |
| Card Number | 4567 8901 2345 6789 |
| Card Type | Credit |
| Issuer | MasterCard |
| Valid From Date | 01/23 |
| Expiry Date | 12/34 |
| Security Code | 123 |
And the card details are valid
When I add the card as a new payment method
Then I should be able to checkout the items in my basket with the card
And I should see the order confirmation screen
Inside the And the card details are valid step, you would have the validation code for all of the items. This may involve breaking down each of these into functions that can be used elsewhere:
public boolean validName(string name){
bool valid = false;
// validate name - set valid to true if it meets validation criteria
return valid;
}
As an example (Java is not my strong point, but this is just an outline on my suggestion).
In essence, making it readable is what cucumber does best, to describe functionality in language that the Development Team and the Business have agreed on, so that everyone can understand exactly what is being described in your Scenario. It's more about conversations than testing things.
Is it like I have done in my example, where you don't necessarily need to validate each card detail individually?
It all comes down to a judgement call.
And if it does come down to this judgement call, where you believe each thing needs to be validated individually, why not use a Scenario Outline to help you out?
Scenario Outline: Valid card details
Given I have a card with the "<detail>" of "<value>"
Then the card detail "<detail>" should be valid
Examples:
| detail | value |
| Name | Mr Test McTestington |
| Card Number | 4567 8901 2345 6789 |
| Card Type | Credit |
| Issuer | MasterCard |
| Valid From Date | 01/23 |
| Expiry Date | 12/34 |
| Security Code | 123 |
I am new to BDD specflow.
I have to write a scenario wherein after I capture an image, i have to select a value for each defined attribute for that image from a selection list
For Eg:
|Body Part |Location |Group |
| Leg | Left | Skin |
| Hand | Upper | Burn |
| Arm | Right | Ulcer |
I need a way in which i can select a different value for each attribute, every time.
Thanks in advance!
You are looking for Scenario Outline;
Scenario outlines allow us to more concisely express these examples through the use of a template with placeholders, using Scenario Outline, Examples with tables and < > delimited parameters.
Specflow takes each line in the Example table and create from the line a scenario to execute.
I am testing out F# and using NUnit as my test library; I have discovered the use of double-back ticks to allow arbitrary method naming to make my method names even more human readable.
I was wondering, whether rightly or wrongly, if it is possible to parameterise the method names when using NUnit's TestCaseAttribute to change the method name, for example:
[<TestCase("1", 1)>]
[<TestCase("2", 2)>]
let ``Should return #expected when "#input" is supplied`` input expected =
...
This might not be exactly what you need, but if you want to go beyond unit testing, then TickSpec (a BDD framework using F#) has a nice feature where it lets you write parameterized scenarios based on back-tick methods that contain regular expressions as place holders.
For example, in Phil Trelford's blog post, he uses this to define tic-tac-toe scenario:
Scenario: Winning positions
Given a board layout:
| 1 | 2 | 3 |
| O | O | X |
| O | | |
| X | | X |
When a player marks X at <row> <col>
Then X wins
Examples:
| row | col |
| middle | right |
| middle | middle |
| bottom | middle |
The method that implements the When clause of the scenario is defined in F# using something like this:
let [<When>] ``a player marks (X|O) at (top|middle|bottom) (left|middle|right)``
(mark:string,row:Row,col:Col) =
let y = int row
let x = int col
Debug.Assert(System.String.IsNullOrEmpty(layout.[y].[x]))
layout.[y].[x] <- mark
This is a neat thing, but it might be an overkill if you just want to write a simple parameterized unit test - BDD is useful if you want to produce human readable specifications of different scenarios (and there are actually other people reading them!)
This is not possible.
The basic issue is that for every input and expected you need to create a unique function. You would then need to pick the correct function to call (or your stacktrace wouldn't make sense). As a result this is not possible.
Having said that if you hacked around with something like eval (which must exist inside fsi), it might be possible to create something like this, but it would be very slow.
In a FitNesse query table, is it possible to load a symbol with the returned results?
example of what I would like to do:
|Query: GetPlayers|
| name | age | ID |
| jones | 36 | $ID1= |
| smith | 27 | $ID2= |
Or alternatively, just have one $ID symbol which is loaded with a collection.
Is this possible?
Unfortunately I believe this is still an unresolved issue in FitNesse. There is a PivotalTracker entry for it, that no one has take one yet: https://www.pivotaltracker.com/story/show/1893214. I've looked at it, but haven't been able to solve it myself.
We currently work around this by having a driver that can do equivalent query. Then we get the value back from the query. It is much more cumbersome, but works for now.
I completely agree that this should be possible. But as far as I know, it has not been fixed yet.
Maybe I don't understand your problem, but this is working fine for me:
|Query: whatever|whatever_param |
|key |value |
|a_key |$symbol= |
|check |$symbol|a_value|
I use Cslim, and the method whatever.query() returns a list of maps that correspond to the keys (the key a_key have the value a_value for this exemple)
I am relatively new to BDD and I have a question regarding scenario outlines. When looking at samples over the internet I have the feeling that the placeholders can take any values. The number of elements in their domain is not restricted. Here is one example:
Scenario Outline: eating
Given there are <start> cucumbers
When I eat <eat> cucumbers
Then I should have <left> cucumbers
Examples:
| start | eat | left |
| 12 | 5 | 7 |
| 20 | 5 | 15 |
The placeholder <start> for example can be any number so the number of values is infinite.
In my specs I have to deal with contracts which can have one of four states (planned, ongoing, paused, and closed). My specs say that I can edit planned contracts but I am not allowed to edit contracts which have one of the remaining three states.
I think I would write a scenario named "Updating a planned contract" and one scenario outline where the status of a contract is a placeholder.
Scenario: Update a planned contract
Given the list of contracts as follows
| name | status | some value |
| c1 | planned | 123 |
And I have edited contract c1 as follows
| field | value |
| name | c1 |
| some value | 456 |
When I save contract c1
Then the list of contracts should be as follows
| name | status | some value |
| c1 | planned | 456 |
Scenario Outline: Update contract
Given there is a <status> contract
And I have edited that contract
When I save that contract
Then I an error 'only planned contracts are allowed to change' should be displayed
Examples:
| status |
| ongoing |
| paused |
| closed |
Is that the right way? One expicit scenario and one parameterized? Or should I write the scenario outline as explicit scenarios for each possibility? I am not sure because the status of a contract is restricted by four possible values as opposed to the examples on the internet.
One thing I find that helps is to remember that Gherkin is just a syntax for Specification by Example. You are trying to provide the examples that make most sense to you in the business domains language.
As such, what you are proposing is perfectly valid. You have one example of a scenario that uses tables to define what happens when a planned contract is edited, and another set of examples that produce errors when contracts in other states. You could also do it explicitly by expanding the outline for each state. Both are valid, and you can always refactor your feature sepcifications as you would the codebase.
What you are aiming to do here however is to provide a grammar, a framework, a language, call it what you will, that you can use to have conversations with your business analysts. You want to be able to pull out this document and say "This is how the system works now, how do we change this to make it support your new feature?".
Personally, I'm avoiding tabular and outline forms in my features right now as I want to make it look as friendly as possible to all I show it to, and as yet, my features are still easy to describe.