There’s a lot of posts out there where people will tell you how to do something. How you must do something in a certain way. How you’re not a real developer unless you do things in this particular way. I hate that sort of post.
I strongly believe that there isn’t such a thing as a best practice. There are effective practices that work well in certain contexts, but might be less effective in other contexts - although I’m pretty confident that some practices aren’t effective in any context. I do, however, think there’s a lot of value to be found in taking a practice that’s successful in one context, and finding ways to adapt or generalise it into more contexts.
So with those caveats out of the way, here’s a post that tries to explain and justify how I personally write my automated tests. These approaches have been shaped over the years by my own experiences but also by the opinions of my colleagues and how well (or not) we’ve seen them work.
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
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
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
When you make a change to user-interface code, how do you know if it does what you expect? How long do you have to wait between typing some code, hitting refresh, and then seeing the result?
There are popular tools to speed up this refresh cycle, but what about user interaction or multiple component states? Even with auto-refresh or hot code reloading you'll usually still have to click on a button to check if your animations are working correctly.
I'll show you how you can get an even better level of immediate feedback from changes. One that lets you see the variety of possible states and interactions your components have all at the same time. This can vastly improve our experiences when building interactive web applications.
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
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
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
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