WIP: Add a guide for BackstopJS regression testing. #22
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… recipe. I also added some additional info for dummies like me!
* Stub for job roles description and impacts * Impact scoring cards draft added * Very big step in reordering messy information * The job roles scorecards are complete and properly linked * A big bunch of work across all information * Impact scoring is in place, with some more info and typo correctsions * Pages sorted * One to one detailed and pages sorted for easier reading * Missions and valus of job roles are defined * Moved pages in the proper section * Better phrasing about lead devs duties * Another rearrangement in proper folders * Reordering in WFSF category * Small correction to the job interviews page * Finished the Job Interview page * Removed refs to billable and non billable time to avoid confusion * Salary page is finally OK * All "todos" addressed. Ready to be tested. * Technical challenges are now up to date * Fixed grammar error * Footnotes and grammatical fixes * Corrections and advancement level notes in ISC * Grammar again * Logged hours are now sustainable by our current rates * Salaries increase for scoring above 2 read easier (small adjustments) * Boons contribute to challenge score * References to advisory board has been removed since it is not formalized to date * ISC expectations have been revised to get rid of numerical constraints * Pointed out the current salary framework is still in early stage * Corrected and extended bits on how evaluation is supposed to be done
noemi-mancini
changed the title
| @@ -0,0 +1,177 @@ | |||
| ## Introduction | |||
|
|
|||
| Billion of words have been spent about test benefits. We're going to spend some here too. Tests are a best practice not because it is funny to talk about (well, maybe it could be), but because they allow you to write down clearly what you're developing, they help you find a bug before your customer do, and they quickly route you on debugging. In short, they save you a lot of time (and stress). | |||
There was a problem hiding this comment.
Suggested change
| Billion of words have been spent about test benefits. We're going to spend some here too. Tests are a best practice not because it is funny to talk about (well, maybe it could be), but because they allow you to write down clearly what you're developing, they help you find a bug before your customer do, and they quickly route you on debugging. In short, they save you a lot of time (and stress). | |
| Billion of words have been spent about test benefits. We're going to spend some more here. Tests are a best practice not because it is funny to talk about them (it is), but because they allow you to nail down the expected behavior of your output: they help you find a bug before your customer do, and good tests also give you clues for debugging. In short, they save you a lot of time and stress. |
|
|
||
| Billion of words have been spent about test benefits. We're going to spend some here too. Tests are a best practice not because it is funny to talk about (well, maybe it could be), but because they allow you to write down clearly what you're developing, they help you find a bug before your customer do, and they quickly route you on debugging. In short, they save you a lot of time (and stress). | ||
|
|
||
| Within visual regression tests, every single person which has ventured into CSS development knows how it's awfully easy to get into truble through the style cascade. Despite the valid methodologies to avoid these issues (BEM, SMACSS, etc), the risk of an unforeseen change is always around the corner. |
There was a problem hiding this comment.
Suggested change
| Within visual regression tests, every single person which has ventured into CSS development knows how it's awfully easy to get into truble through the style cascade. Despite the valid methodologies to avoid these issues (BEM, SMACSS, etc), the risk of an unforeseen change is always around the corner. | |
| Within visual regression tests, who ventured into CSS development knows how awfully easy it is to get into trouble through the style cascade. No matter how valid the method to avoid these issues (BEM, SMACSS, etc), the risk of unforeseen changes is always around the corner. |
Also, I can't get what that starting "within" is about? Did you mean "Talking about..." maybe?
|
|
||
| Within visual regression tests, every single person which has ventured into CSS development knows how it's awfully easy to get into truble through the style cascade. Despite the valid methodologies to avoid these issues (BEM, SMACSS, etc), the risk of an unforeseen change is always around the corner. | ||
| Can you say how long it takes to check, at every change in code, every single page for every single breakpoint? And when page number increases, manual visual testing takes more and more time. | ||
| A VR test does all these tasks for us, in a matter of minutes. |
There was a problem hiding this comment.
A general comment on the whole page: since this is not a blog post, but a guide, we should assume the reader to know what we are talking about and what value is conveyed by VRTs.
I would indeed take this whole first part and make a post for our tech-blog out of it, leaving the next paragraph as the opening for this guide.
How does this sound?
|
|
||
| _Source:_ [#982 Error running scenarios in docker image 3.9.2](https://github.com/garris/BackstopJS/issues/982) | ||
|
|
||
| BackstopJS is not in each of our projects yet, so we're going to install it in specific prjects when needed. Follow us: |
There was a problem hiding this comment.
Please, take a note to correct both those information as long as:
- that bug is solved
- the tool has been integrated in our standard codebases (make it clear in the guide)
|
|
||
| BackstopJS documentation is rather exhaustive, but we think it's usefull to give you some clues that can save you time and effort. | ||
|
|
||
| **Note: ** at time of writing, latest version (3.9.2) seems to be broken and makes tests fail, so if you're building a new prject, please check you're using the version 3.9.0. |
There was a problem hiding this comment.
Suggested change
| **Note: ** at time of writing, latest version (3.9.2) seems to be broken and makes tests fail, so if you're building a new prject, please check you're using the version 3.9.0. | |
| **Note:** at time of writing, latest version (3.9.2) seems to be broken and makes tests fail, so if you're building a new prject, please check you're using the version 3.9.0. |
There was a problem hiding this comment.
The unwanted space breaks the bold styling, propagating it to all the next section, up to EOL 47.
|
|
||
| **Note:** you can find lots of details in the official documentation, but if you stumbled upon an issue that's not covered there, we'll be happy to update this doc for future reference. | ||
|
|
||
| It's important to point out that a single scenario can generate multiple screenshots. This is most important when we need to test user interactions more complex than a single click. |
There was a problem hiding this comment.
Suggested change
| It's important to point out that a single scenario can generate multiple screenshots. This is most important when we need to test user interactions more complex than a single click. | |
| It's worth pointing out that a single scenario can generate multiple screenshots, for example every time we test user interactions more complex than a single click. |
|
|
||
| It's important to point out that a single scenario can generate multiple screenshots. This is most important when we need to test user interactions more complex than a single click. | ||
| > A scenario represents a single state for your app. Given that state, a screenshot will be generated for each DOM selector you specify. | ||
| #406](https://github.com/garris/BackstopJS/issues/406) |
There was a problem hiding this comment.
Is there a missing [ or something here?
| > A scenario represents a single state for your app. Given that state, a screenshot will be generated for each DOM selector you specify. | ||
| #406](https://github.com/garris/BackstopJS/issues/406) | ||
|
|
||
| **Note:** for now, this seems to be an issue, as stated on [#807 two times clickselector or clickselectors doesn't seem to work](https://github.com/garris/BackstopJS/issues/807) |
There was a problem hiding this comment.
Suggested change
| **Note:** for now, this seems to be an issue, as stated on [#807 two times clickselector or clickselectors doesn't seem to work](https://github.com/garris/BackstopJS/issues/807) | |
| **Note:** for now, this seems to be an issue, as stated in [#807 two times clickselector or clickselectors doesn't seem to work](https://github.com/garris/BackstopJS/issues/807) |
|
|
||
| ### Need help or want to improve the doc? | ||
|
|
||
| Do you think this documentation lacks some important info? Drop up a line with your question or [fork the project on GitHub](https://github.com/sparkfabrik/company-playbook) to add your suggestions. |
There was a problem hiding this comment.
This is a CTA that we generally don't want in our playbook. Not that we don't want contributions, but we don't want to engage people in discussion: this is Sparkfabrik handbook and is true for us, it should not substitute official documentation (I would invite the community to contribute back to backstop in fact).
Still this makes for a good CTA on a blog post.
I would remove it and move the original file to a blog post.
| ] | ||
| } | ||
| ``` | ||
|
|
There was a problem hiding this comment.
A small walkthrough would also comes in handy.
|
@noemi-mancini untill you'll take the time to review this, please add a |
noemi-mancini
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is in WIP because it lacks an intro.