I have 135 Test Cases (and growing), and I can't seem to figure out how I can divide my test cases into different sections.
For example, I want my regression test cases to be part of a separate table, and stats test cases to be part of a separate table instead of a single long table. How would I go about doing something like this?
You can achieve this using allure reporting
https://docs.qameta.io/allure/
Related
Is it possible to create a view of summarizing test point outcome by tester? If yes, how can this be done?
I am using Azure DevOps to track the testing progress on my project. I have defined test plans for each Sprint, with multiple testers, test cases and test points assigned to each sprint.
It's possible to create a matrix with Testers as rows and Outcomes as columns for each particular Sprint.
I want to create a sort of an aggregated view over all Sprints, but using a query to summarize information from multiple test plans only allows me to look at test cases, not test points. Hence, I get "State" as column options, rather than "Outcome". Is it possible to query over test points in some other way? https://learn.microsoft.com/en-us/rest/api/azure/devops/test/points/get-points-by-query?view=azure-devops-rest-6.0 this suggests its doable, but I can't understand how to use the UI to get it.
Thanks a lot!
Assume that I have a Spock specification that given a city and state tests for the correct zip code. Assume I have a text file of cities and states that is used to drive the tests in the where clause.
Now assume that I want to split the tests so that I can run for "Virginia" or "Maryland". The approach that I have taken is to create a new VirginiaSpec and a new MarylandSpec and in that spec, I modify the where clause.
This works, but seems inefficient because every other part of the VirginiaSpec and MarylandSpec is exactly the same. In addition, if the logic changes, then I would need to change it in every spec that I have.
So what I am looking for is an approach that allows me to have one StateSpec in which the where clause can be parameterized.
I realize I have not included a code example, however if my question is not clear, then I can provide one. Thanks for your help.
-Dan
You have a couple of options. You could put the basic setup and structure and even the test itself in a base test class, then extend that class w/ your VirginiaSpec and MarylandSpec. Your spec classes would be very small probably just defining a constant that is the state for the spec.
But that seems needless. If both the cities and states are in this file, you could just read in the file in the where section of your test.
https://snekse.github.io/test-often-and-prosper-slides/#/42
If you cannot get the WHERE section working, you could always read in your file during the setupSpec and store the data in some kind of data structure then loop through it.
Spock: Reading Test Data from CSV File
But in general, using the Where label is going to be the right answer.
I am reading a lot about Gherkin, and I had already read that it was not good to repeat steps, and for this it is necessary to use the keyword "Background", but in the example of this page they are repeating the same "Given" again and again, Could it be that I am doing wrong? I need to know your opinion about it:
Like with several things, this a topic that will generate different opinions. On this particular example I would have moved the "Given that I select the post" to the Background section as this seems to be a pre-requisite to all scenarios on this feature. Of course this would leave the scenarios in the feature without an actual Given section but those would be incorporated from the Background section on execution.
I have also seen cases where sometimes the decision of moving steps to the Background is a trade-off between having more or less feature files and how these are structured. For example, if there are 10 scenarios for a particular feature with a lot of similar steps between them - but there are 1 or 2 scenarios which do not require a particular step, then those 1 or 2 scenarios would have to moved into a new feature file in order to have the exact same steps on the Background section of the original feature.
Of course it is correct to keep the scenarios like this. From a tester's perspective, the Scenarios/Test cases should run independently, therefore, you can keep these tests separately for each functionality.
But in case you are doing an integration testing, then some of these test cases can be merged, thus you can cover multiple test cases in one scenario.
And the "given" statement is repeating, therefore you can put that in the background, so you don't have to call it in each scenarios.
Note: These separate scenarios will be handy when you run the scripts separately with annotation tags, when you just have to check for a specific functionality, or a bug fix.
Begging a pardon in advance for a newbie question.
I'm writing a feature where visitor of the page should see several attributes of an item.
The question is shall I add a separate feature for each attribute or separate scenarios of the same feature or create a single column table in then clause listing all attributes that should be displayed?
I'd put all of the assertions in the same scenario unless there's a good reason to separate them. It would take a lot longer to run if it has to get to the page to assert on multiple times.
The decision to use multiple 'Then ...' lines or to use a table is mainly a matter of personal taste as both will work. Personally if there are only a couple of assertions then I just use multiple Then lines, but if there are more than that I use a table.
For example, I have a list of ids for a product that lives in a database and is updated daily. I need to be able to run a scenario that consumes that data and runs the same steps over each of the ids in order. However, the test should not stop because one of the ids failed in the scenario, similar to what cucumber does with the scenario outline type of tests.
We would also want to format the output of the cucumber test(s) so that each id is formatted as if it is a separate test or example in a "scenario outline."
I believe I did something similar some time ago. Have a look at this feature definition.
The "Then I should be able to get to the browse categories page" action is defined here and, as you can see, Category at line 59 retrieves data from this class. In this case I'm getting data from a CSV file, but you can just substitute it with your DB.
My Ruby is a bit basic so the code style might not look so good, but it is an example I had around to easily explain what I did. Hope this help!
Cucumber is not designed to write complex information in feature file ,
If your Data is complex , or dynamically generated , you should get Data in step definition and write a generic term in feature file .
That's the intention of cucumber , writing simple features so that non technical person can easily understand what the scenario is doing.