You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AFAIU, your approach is to have the data in a fixture file and then write the test so its behavior depends on the data. I see the advantages it has when compared to the initial version of the test code. Still, I believe we can go one step further.
The problem with your approach is that your test is limited to what the data contains. What if you want to test what is displayed when an article doesn't have any tag? You have to add this case to the fixture file (for the UI test). What if you want to test what happens when the description of an article is very long? Same answer. So your fixture depends on what you want to test and several tests and tests files will impose different requirements on the shared fixtures. This will make it hard to change the fixture file.
A possible solution is to let the test change the data so the data is exactly what the test needs. E.g.,
The above code expects an "article.json" fixture file and produces 2 articles with different slugs, different titles and no tag. This way, the test can check what happens when an article has no tag.
Here is the Cypress command makeModelsFromFixture():
/** * Create several copies of a JSON fixture and yield them. * * @arg {string} fixture - The path of the JSON fixture to clone. * @arg {int} number - The amount of clones to create. This is the * size of the returned array. * @arg {replacement} function - Takes a number from 1 to `number` and * should return a literal object used to override part of the fixture. */Cypress.Commands.add("makeModelsFromFixture",({ fixture, number, replacement })=>{returncy.fixture(fixture).then((template)=>{returncy.makeModelsFromTemplate({
template,
number,
replacement,});});});/** * Create several copies of a template and yield them. * * @arg {object} template - An object to clone. * @arg {int} number - The amount of clones to create. This is the * size of the returned array. * @arg {replacement} function - Takes a number from 1 to `number` and * should return a literal object used to override part of the template. */Cypress.Commands.add("makeModelsFromTemplate",({ template, number, replacement })=>{letmodels=[];for(leti=1;i<=number;i++){models.push(Object.assign({},template,replacement(i)));}returnmodels;});
The text was updated successfully, but these errors were encountered:
AFAIU, your approach is to have the data in a fixture file and then write the test so its behavior depends on the data. I see the advantages it has when compared to the initial version of the test code. Still, I believe we can go one step further.
The problem with your approach is that your test is limited to what the data contains. What if you want to test what is displayed when an article doesn't have any tag? You have to add this case to the fixture file (for the UI test). What if you want to test what happens when the description of an article is very long? Same answer. So your fixture depends on what you want to test and several tests and tests files will impose different requirements on the shared fixtures. This will make it hard to change the fixture file.
A possible solution is to let the test change the data so the data is exactly what the test needs. E.g.,
The above code expects an "article.json" fixture file and produces 2 articles with different slugs, different titles and no tag. This way, the test can check what happens when an article has no tag.
Here is the Cypress command
makeModelsFromFixture()
:The text was updated successfully, but these errors were encountered: