To add a collaborator to this project you will need to use the Relish gem to add the collaborator via a terminal command. Soon you'll be able to also add collaborators here!More about adding a collaborator
Notes on Cucumber
Feel free to add tags (such as
@wip to the various scenarios). When running tests we can run specific tags if need be.
What I would like to get is a subset of all of our features/scenarios to be identified as a "smoke test" (ideally, tagged as
These would be the core functionality of the product, without getting into the nitty-gritty.
Features should be broken out into seperate .feature files. This is how cucumber will run them. This also makes it easier to read and find specific areas of the app. Additionally, do not number the Features or Scenarios, as that is not how the gherkin syntax works. I would recommend using some text editor (such as sublime 3) to edit
.feature files. Make sure you install a cucumber/gherkin syntax highlighter (and possibly formatter) to make it a bit easier to create these file types.
These all look really great. One area that I think we need some improvement on is what it takes to get to a certain state. They way I want to see test made is that they are all self inclusive. What I mean by that is that if you were to rip out this test and run it just by itself, it should be able to work fine. To achieve this, tests may need a bit of setup.
Additionally, and this is where it can get a bit hard, but steps should be fairly concise. What I don't want to see is a huge long step that does tons of action in the end. These kinds of steps should be broken down into other steps (which makes it easier to read, and makes these steps more reusable).
Cucumber has some features where if we want to make a compound step, we can add various steps into this compound step, but for now, it's best to keep them short and concise.
One more thing, you need to consider what settings are enabled/disabled while the tests are being run. Never assume that some setting will be on, you need to explicitly set those settings.
If you look at some of my scenarios you can see how I setup the settings (usually in a Background step).
You can use a Background condition to run duplicated steps before each case, this can save alot of typing/repetition. If you check out the repository, you can see how I use this.
I've created various folders and put the tests in them. I try to make folders based on functionality on the site to organize the cukes.
Description of Feature
Each feature should only have 1 description for it (the text that goes beneath the "Feature:..." at the top). I usually put it in a format like:
Because I am something/want to do something When I perform an action I expect this result
I formatted all of the tests in this repo, please follow this same formatting (as seen below)
Feature: Base level indent Description is Indented only Once. Background: Is the same as description, if you have one. Given Steps are then indented once from the scenario/background. Scenario: Is, again, the same as the description. Given Steps are then indented once from the scenario/background. When another step Then my last step @Tag @Bob Scenario: A tag can just be like above, you can put multiple if need be Given test step When another step Then final step
Areas we can't/are difficult to automate
- Visual issues
Last published almost 7 years ago by blubecker.