5 Habits to Treat Your Test Code Like Production

Rate this content
Bookmark

In this talk, David will talk about 5 habits that you can follow to ensure the same quality as your production code and building test suites that are robust, consistent and help you debug the issues quickly.

- Typical journey for teams adopting test automation 

- 5 habits to follow while building your test suite 

- Our learnings from a recent refactoring activity

This talk has been presented at TestJS Summit 2022, check out the latest edition of this JavaScript Conference.

FAQ

The presentation discusses breaking down tests to make them manageable, treating test code with the same rigor as production code, improving tooling for testing, and optimizing tests to reduce flakiness and enhance maintainability.

Unit tests are important because they are small and should be numerous to ensure that each component or function of the software works correctly in isolation, which helps in quickly identifying problems in the early stages of development.

Making tests less flaky can be achieved by breaking down tests into smaller, more modular parts, ensuring that tests are fast and manageable, and focusing on component testing rather than just relying on end-to-end tests.

Effective tooling helps keep developers in flow, allowing them to run tests efficiently without leaving their development environment. This can include using tools like VS Code extensions that integrate testing capabilities directly into the IDE.

Test code should be updated regularly to incorporate new features, address bugs, and ensure compatibility with the latest versions of dependencies, similar to how production code is maintained.

UI tests should be broken down into smaller, more manageable parts rather than relying on extensive end-to-end tests. This approach speeds up testing and reduces the complexity and flakiness associated with larger tests.

Treating SDETs like other engineers, including equitable pay and recognition, is crucial because they play a key role in designing and maintaining the test architecture, which is essential for producing reliable software.

David Burns
David Burns
22 min
03 Nov, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Today's Talk focuses on the five habits to treat test code like production code. It emphasizes the importance of modular testing and breaking down UI tests into smaller components. Treating SDETs as software engineers is crucial for code and test quality. The challenges of snapshot testing and the benefits of component testing are also discussed, including improved efficiency and addressing asynchronicity and nested promises.

1. Introduction

Short description:

Today I'm going to be talking about the five habits to treat your test code like you would production code. My name is David Burns, I head up the Open Source Program Office at Browserstack and I'm the chair of the browser testing and tools W3C working group. By the end of today, we're going to be able to take something away and see how you can rejig everything you do at work to make your lives easier.

Hi, everyone. Today I'm going to be talking about the five habits to treat your test code like you would production code. So, first of all, who am I? My name is David Burns or as most people tend to know me, automated tester. I head up the Open Source Program Office at Browserstack. I'm the chair of the browser testing and tools W3C working group. I'm a Selenium and a Nightwatch JS committer. I've been in this industry for a while. And so hopefully by the end of today, we're going to be able to kind of take something away and see how you can rejig everything you do at work so you can make your lives actually easier.

2. Approach to Testing and the Testing Pyramid

Short description:

In this part, we will discuss how people tend to approach testing on projects and how to break down testing to make it manageable, maintainable, and less flaky. We will also explore the importance of treating test code like production code and improving tooling. Additionally, we will examine the testing pyramid, which includes unit tests, service tests, and UI tests, and the trade-off between isolation and integration. Finally, we will address the issue of overloading unit tests and the resulting challenges in maintaining them.

Here's our agenda. I'm going to look at how people tend to look at their testing on projects, how we can break down testing to make it manageable, maintainable and less flaky. That's the most important part. How to treat your test code like production code. So what we do with the last part and how to improve your tooling and actually why this matters. You'll be surprised. So let's get started and see where we go.

Now, I've been working in testing for many, many years and I tend to see how people look at testing from different ways. And if we look at it from the textbook way, this is how people should be doing it. At the bottom, we have the testing pyramid here. At the bottom, we have the unit tests. The reason why that is important is because the reason why that is wider is that there should always be a lot more of them than any other tests in our test code. Then we have service tests. These are our integration tests. These are all kind of like if unit tests are small, service tests tend to be medium and kind of start bridging gaps between all our little components of code or like atomic areas of code. And starts getting us towards the next part, which is our UI tests. Now, one of the things I didn't put in here is manual testing. Generally, I tend to speak about automated testing, but this is not to take away from manual testing. And if you have a look at the arrows on the side, is that you've got on the left hand side, as I look at the screen, more isolation to more integration. So the higher you go, more integration you're going to need and less isolation. Yet, the downside of when you add more integration is that things will get slower. This is just general computer science, right. The more code that has to be processed, the slower it will be, right. If you do a loop within a loop, you know that's going to be slower than a single loop trying to find something. Ideally, we need to be trying to make super fast tests and a lot fewer slower tests. Unfortunately, especially from what I see, and I appreciate there might be a lot of bias, having worked on Selenium and NightwatchJS for many, many years, is that people do unit tests. These are generally done by your developers, and they're done with jest, or Karma, or things like that, and people put a lot of effort into them. Then you'll start getting some service tests or these integration tests, and so I took my image here from Martin Fowler's work, and I've kind of rejigged it a bit. Then, especially now that I see this in browser stack and kind of speaking to customers, and when I was at Mozilla, kind of speaking to Selenium users, people tended to throw everything, and I mean everything, at their unit tests. They would bulk it up, put tons of tests, and then slowly but surely, the test would become unmaintainable.

QnA

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Atomic Deployment for JS Hipsters
DevOps.js Conf 2024DevOps.js Conf 2024
25 min
Atomic Deployment for JS Hipsters
This Talk discusses atomic deployment for JavaScript and TypeScript, focusing on automated deployment processes, Git hooks, and using hard links to copy changes. The speaker demonstrates setting up a bare repository, configuring deployment variables, and using the post-receive hook to push changes to production. They also cover environment setup, branch configuration, and the build process. The Talk concludes with tips on real use cases, webhooks, and wrapping the deployment process.
Effective Performance Testing to your Server with Autocannon
TestJS Summit 2021TestJS Summit 2021
36 min
Effective Performance Testing to your Server with Autocannon
Top Content
Tamar is an experienced code writer and architect with expertise in Node.js. Performance testing can be confusing, but understanding terms like throughput and the 99th percentile is crucial. The 99th percentile is important for making commitments and ensuring customer satisfaction. AutoCanon is a powerful tool for simulating requests and analyzing server performance. It can be installed globally or used as a library in Node.js. Autocannon is preferred over Gatling for performance testing and can be integrated with end-to-end tests in Cypress.
Delightful Integration Tests With Testcontainers
TestJS Summit 2022TestJS Summit 2022
21 min
Delightful Integration Tests With Testcontainers
Top Content
Testing is crucial for development and production, with integration tests becoming more popular. Test containers is a library that integrates with Docker to create reliable test environments. It is flexible and can be used with various frameworks and test libraries. The IDE setup involves configuring the container and connecting it to the application. Test containers can be used for complex operations and allows running tests with real dependencies.
Visual Regression with Puppeteer, Playwright and Cypress
TestJS Summit 2021TestJS Summit 2021
9 min
Visual Regression with Puppeteer, Playwright and Cypress
Top Content
Hello, I'm Rainer Haneckamp, a trainer and consultant at Angular Architects. In this talk, we'll explore visual regression testing using tools like Puppeteer, Playwright, and Cypress. We'll learn how to use Storybook and Puppeteer with Jest for visual regression testing. We'll also see how Jest and Playwright can be used together for visual regression testing. Finally, we'll discover how to use Cypress for visual regression testing. Thank you for watching!
Playwright Can Do This?
TestJS Summit 2022TestJS Summit 2022
23 min
Playwright Can Do This?
Playwright is a powerful tool for end-to-end testing, offering support for all major browsers and platforms. It provides features like parallelization, built-in waiting, and assertions. Playwright allows for running tests on multiple browsers with a single command and has functionality for generating tests and performing visual regression testing. It also enables the manipulation of the network layer and loading internals of web pages. Best practices include using short and idempotent scripts, splitting user account flows into separate tests, and cleaning up after each test case.
The Lazy Developer Guide: How to Automate Code Updates?
DevOps.js Conf 2022DevOps.js Conf 2022
22 min
The Lazy Developer Guide: How to Automate Code Updates?
Code automations can save time and effort in development tasks. There are tools and examples available for automating tasks like updating dependencies and code formatting. Automation allows teams to focus on valuable work and improves overall performance. Deciding when to automate depends on the impact and type of code. The last automated task discussed was applying translation updates to multiple projects.

Workshops on related topic

Automated accessibility testing with jest-axe and Lighthouse CI
TestJS Summit 2021TestJS Summit 2021
85 min
Automated accessibility testing with jest-axe and Lighthouse CI
Workshop
Bonnie Schulkin
Bonnie Schulkin
Do your automated tests include a11y checks? This workshop will cover how to get started with jest-axe to detect code-based accessibility violations, and Lighthouse CI to validate the accessibility of fully rendered pages. No amount of automated tests can replace manual accessibility testing, but these checks will make sure that your manual testers aren't doing more work than they need to.
Automated Testing Using WebdriverIO
TestJS Summit 2022TestJS Summit 2022
163 min
Automated Testing Using WebdriverIO
Workshop
Kevin Lamping
Kevin Lamping
In this workshop, I cover not only what WebdriverIO can do, but also how you'll be using it day-to-day. I've built the exercises around real-world scenarios that demonstrate how you would actually set things up. It's not just "what to do," but specifically "how to get there." We'll cover the fundamentals of Automated UI testing so you can write maintainable, useful tests for your website and/or web app.
JS Security Testing Automation for Developers on Every Build
TestJS Summit 2021TestJS Summit 2021
111 min
JS Security Testing Automation for Developers on Every Build
WorkshopFree
Oliver Moradov
Bar Hofesh
2 authors
As a developer, you need to deliver fast, and you simply don't have the time to constantly think about security. Still, if something goes wrong it's your job to fix it, but security testing blocks your automation, creates bottlenecks and just delays releases...but it doesn't have to...

NeuraLegion's developer-first Dynamic Application Security Testing (DAST) scanner enables developers to detect, prioritise and remediate security issues EARLY, on every commit, with NO false positives/alerts, without slowing you down.

Join this workshop to learn different ways developers can access Nexploit & start scanning without leaving the terminal!

We will be going through the set up end-to-end, whilst setting up a pipeline, running security tests and looking at the results.

Table of contents:
- What developer-first DAST (Dynamic Application Security Testing) actually is and how it works
- See where and how a modern, accurate dev-first DAST fits in the CI/CD
- Integrate NeuraLegion's Nexploit scanner with GitHub Actions
- Understand how modern applications, APIs and authentication mechanisms can be tested
- Fork a repo, set up a pipeline, run security tests and look at the results
Security Testing Automation for Developers on Every Build
GraphQL Galaxy 2021GraphQL Galaxy 2021
82 min
Security Testing Automation for Developers on Every Build
WorkshopFree
Oliver Moradov
Bar Hofesh
2 authors
As a developer, you need to deliver fast, and you simply don't have the time to constantly think about security. Still, if something goes wrong it's your job to fix it, but security testing blocks your automation, creates bottlenecks and just delays releases, especially with graphQL...but it doesn't have to...

NeuraLegion's developer-first Dynamic Application Security Testing (DAST) scanner enables developers to detect, prioritise and remediate security issues EARLY, on every commit, with NO false positives / alerts, without slowing you down.

Join this workshop to learn different ways developers can access NeuraLegion's DAST scanner & start scanning without leaving the terminal!

We will be going through the set up end-to-end, whilst setting up a pipeline for a vulnerable GraphQL target, running security tests and looking at the results.

Table of contents:
- What developer-first DAST (Dynamic Application Security Testing) actually is and how it works
- See where and how a modern, accurate dev-first DAST fits in the CI/CD
- Integrate NeuraLegion's scanner with GitHub Actions
- Understand how modern applications, GraphQL and other APIs and authentication mechanisms can be tested
- Fork a repo, set up a pipeline, run security tests and look at the results