“I ship CSS as soon as the tests pass. (I’m not crazy)”
To this day I remember how at my first job as a frontend developer the product I was working on crashed. And it did it in the most sneaky way - not completely, just partially. Elements of some charts were misplaced, buttons misaligned and part of the app wasn’t being rendered at all if the API was returning a particular response. I was ashamed of that! And what’s even worse - I felt powerless. I wasn’t new to IT. By that time I had years of experience as a backend developer. When testing backend APIs, I was able to automate precise assertions and ship my code as soon as I saw the tests passing. But that testing expertise didn’t directly translate to the mysterious world of HTML, CSS and JS. I wrote plenty of tests and yet I felt the need to manually test the application before pushing the code, just in case some layout was off or some API responses caused it to malfunction. I began to ask myself a question: Is this what testing the web looks like? It was a grim vision I didn’t want to accept.
That’s why I embarked on a journey to find a testing solution powerful enough for me to be able to confidently ship my Single Page Applications without ever testing them manually. I found stateful API mocking tools based on a concept called Finite-State Automaton. They allowed me to mimic complex server behavior, such as handling POST requests, in a way that looked more like writing down examples of requests and responses than re-implementing the entire backend in my mocks. I learned about visual regression tests which basically mean assertions about how things look. And we’re talking pixels here, not abstract structures like the number of DOM nodes of particular kind. I also discovered some really smart ways to select elements I want to interact with in my tests in a way that’s similar to the way the user would locate them, that is through labels and roles. So, does it means that I was able to simply install some package and start testing? Sadly, no. There was no easy way to do all that in one test. But now there is! By the end of this talk, you’ll know the secrets that enabled me to deliver multiple Single Page Applications without running them outside of the automated testing environment even once!
Join me and discover:
- Why do we automate tests?
- Why mocking POST requests can be challenging and what can you do about that?
- What the font-weight property can tell you about your tests?
- How screenshots can help in testing?
- What do you have to have in your toolbox if you want to rely on tests while developing SPAs?
- How visual tests can foster communication between frontend developers and product owners?
- How does it feel to implement new features when you have all the necessary testing tools in place?
Bio
Łukasz Makuch has been working with computers since his parents bought an IBM 8088 PC in the early 1980s. He has over 15+ years professional experience in the IT industry creating a variety of products for the web and desktop. He’s done everything from using third party PBX, and WebRTC software to build communication solutions for call centers and other businesses, using Websockets and other server-push technologies to route work to people, building out CI and automation workflows, to leading and coaching teams on good development practices, which build world class organizations. James is an avid learner who believes in standing on the shoulders of giants. He spends time every day listening to podcasts and reading articles from industry leaders.
Social networks
- -> Github
- -> Coder.earth