Exploring Node Modules for Test Automation

Rate this content
Bookmark

In my talk I will explore the challenges faced when trying to manage and maintain test code across multiple projects and what made me create my first Javascript module. I will showcase the process of building, publishing, and versioning it using the powerful capabilities of GitHub Actions. And finally, I will talk about the benefits of doing it.

19 min
11 Dec, 2023

AI Generated Video Summary

This Talk explores the process of building a test automation library using node modules, with a focus on creating the project structure, building and testing the library, and publishing and versioning the package. It discusses the inclusion of helpful features like WAIT helpers and the use of libraries like Playwright and Cypress. The importance of clear documentation, pre-release versions, and version control is emphasized, along with the need for installation instructions and contribution guidelines.

1. Introduction to Building Test Automation Library

Short description:

I will be talking about exploring node modules for test automation. I will talk you through the process of building your own library, publishing to npm, and then using it. Today, I will be talking about creating a module project with PMPM and VIT. I will be talking about test-driven development, testing it. I will be talking about selecting NPM registries, so where you will publish your package. I will show you example of the GitHub pipeline workflow used to publish a new release, but also pre-releases. I will be talking about the versioning of the project is really important and importance of adding Readme. But before we start to dive into how to build your own library, I would like to ask the question, and maybe discuss first, what this library would include? What sort of helpers? You find yourself often copy-pasting from project to project, so what helpers would be good to be in this test library? I often find myself using WAIT helpers. It doesn't matter if you work with Playwright, Cypress, Selenium.

Hello, everyone, my name is Kat Kniotek. I work as a quality engineer at Houseful, previously known as Zoopla. Thank you for joining my talk today.

I will be talking about exploring node modules for test automation. I will talk you through the process of building your own library, publishing to npm, and then using it.

So, we may start with the question, why? Why would you create your own library for test automation? So, I was working with two approaches for the tests. First one, the test framework would live in a separate repository. Would be a single place to manage test dependencies. The test would be sharing helpers and setup methods. Tests would be maintained by the QA team. You could have separate frameworks for UI and for the API tests, but mainly QA team would be responsible for updating it, adding it, debugging flaky tests. The second approach I worked with, and I'm being honest, favor is that tests live with the project, with the application project. And then they can be maintained by developers. So, let's say I would set up this framework and the developers would be adding tests, updating tests as required. However, this approach introduced lots of code duplication. Every time we're creating new API, new service, I would find myself copying, pasting from one project to another helpers, the setup configuration for the project. And also when I had to update one of the dependencies, test dependencies, I had to update in the five places. It wasn't really a way to go. That's why I decided to look into building my own library that would include all the helpers that I copy-paste from repository to repository. I could just install this library in a project and then use helpers as and when required.

So today, I will be talking about creating a module project with PMPM and VIT. I will be talking about test-driven development, testing it. As automation engineers, not often do we have opportunity to practice TDD. This is the opportunity. I will be talking about selecting NPM registries, so where you will publish your package. I will show you example of the GitHub pipeline workflow used to publish a new release, but also pre-releases. I will be talking about the versioning of the project is really important and importance of adding Readme. Those are a few checkbox that I will be talking about. But before we start to dive into how to build your own library, I would like to ask the question, and maybe discuss first, what this library would include? What sort of helpers? You find yourself often copy-pasting from project to project, so what helpers would be good to be in this test library? I often find myself using WAIT helpers. It doesn't matter if you work with Playwright, Cypress, Selenium.

2. Creating Test Library and Project Structure

Short description:

We can store our custom WAIT helpers, matchers, assertions, and configuration in the test library. Authentication methods, page object models, and API client helpers can also be included. To create the library, we can use the command line tool for pnpm and answer a few questions about the framework, selecting the runtime as library and the language as TypeScript for type safety.

We all have our custom WAIT helpers that are probably particular for the application we work on, and they can be stored within our new test library. Maybe you created your custom matchers and assertions, and you really like the way how they work, and you want to use them in other projects. So instead of copy-pasting, you can place them in this test library.

Configuration of your test, that can be shared as well. Authentication methods, so let's say that you work with, you test API, and the authentication for the service is CognitoToken, and each of the APIs, each of the projects use the same authentication method. So you have this helper to calculate base64 token from credentials. This can go to the helpers library as well. Page object models, maybe each of your tests interact with the login page, and the login page is the same for all applications. Maybe this login page, page object model could live in the library. And API client helpers and setup, setting up custom headers and so on.

So when we are starting the command line, instead of like doing all the project setup and so on, we can use the command line tool for pnpm and create the bit project. You will be prompted to answer a few questions around the framework. We are not using any react view or anything. We're just using other. Runtime to select will be library. That's really handy because that's what we are building. Language, I selected TypeScript to make our library type safe. If you ever used that sort of command line tool, like NPX, create React app or similar, you know that that's what will build for you like the project structure with lots of boilerplate. Code.

3. Building and Testing the Library

Short description:

In our example, we can remove everything that is related to HTML. We won't be running our application in the browser. So HTML, CSS, SVG, they won't be useful in our project. You can start installing your favorite libraries like playwright, Cypress, FakerJS. All your helpers should go to the lib directory in the main TS file. Once you have all your helpers defined, you can export them in an index.d.ts file.

In our example, we can remove everything that is related to HTML. We won't be running our application in the browser. So HTML, CSS, SVG, they won't be useful in our project. Then you can start installing your favorite libraries. So let's say playwright, let's say Cypress, FakerJS or similar ones. And all your helpers should go to the lib directory, to main TS file. And here is an example how my main TS file looks like. It has a few methods, a few functions. The first one is the one that I mentioned, I like to use a custom wait helper. This is for playwright. I wait for a particular particularly response in the network tab, and then carry on with my tests. The one I mentioned as well, calculating cognito token from environment variables and returning the string, and demo helper to just print hello, name. So something fairly easy, easy to test. And then once you have all your helpers defined, well, you can start with one or a few. You need to export them in a index.d.ts This file is by default in your root of your project. So then here you export those functions that will be available from the library.

Okay, so what then? Testing. You can install vtest. Let's say you can add your unit tests for your methods, and of course make sure that the test stage is included in the pipeline in the workflow. But how we actually test our solution? So, we build the project, and, in theory, it's all good because we just copy the code over, work somewhere else, how we test it, we can actually install it and access those methods that are publicly accessible once the package is built. So, we will build the project, and then we will pack it. So something that will happen in the pipeline, in the pipeline we'll build, and then we'll publish. Published by default packs our project. And as the output of the PMPM pack command, there will be a file created, that is basically a name of the project from package.json with the version number. And this is our library. How we can test it. We can create the separate project and just install it. Something that I learned as part of the working on this project is that you can actually install the library from the file. So if you would run pmpm install path to your file, as you can see on the example, that will be installed in your package.json. It's fantastic.

4. Testing and Publishing the Package

Short description:

You can test your package by importing it and updating the methods if needed. To make your package available, you can store it in npm or use GitHub feed. GitHub workflow can be used to publish the package, including pre-release versions. The workflow triggers on pull requests and authenticates your login to the npm registry.

And then you can just test it like import print hello from my test helpers, and it works. Well, didn't work with the first time. So don't discourage yourself if it won't work with the first time. You can just update the methods. Maybe you forgot to export it in the index file, rebuild it and publish it again, pack it again. It's obviously a trial and error and it's a great learning.

So once we have our project built, we know that it works because we can install it in another project. We need to start thinking how we will make it available across repositories and in other teams. One of the solutions for publishing our package would be to store it in npm. You can sign up to npm and publish your package there. If you are using free account, you are allowed to publish public packages. However, if you feel that your project, your module contains something related to the application, you don't want to expose this to outside world or something, you just don't want to make it public, you would need a paid account or enterprise level. Because I don't have it, I decided to publish my package with GitHub feed. It's also npm registry. You just specify a different registry URL that is pointing to your GitHub registry. You can also create the package on the organization level. You can make it private, public. Here's just an example. I was using my own GitHub account.

So we could use all the commands like build, pack, publish locally. We could log into registry locally and publishing it from there. However, from maintenance point of view, we wanted to be controlled by source control, by version control. So here is the example of a GitHub workflow that will be publishing our package. It will be publishing pre-release package. I'll be talking about it later. But what you can see here is a trigger. So this workflow will be triggered every time there is a pull request created against the main branch. This will check out our code and will create a .npmrc file. This file is used to authenticate your login to the npm registry. Because as you can see on the second line, 19, it includes the secret.

5. Publishing and Versioning the Package

Short description:

I didn't want to commit it to the repository. That's why I write to the file as a pipeline step and I have access to my secret here. When you run the pipeline, the output looks more or less like this. It is on line 12, you have your index.d.ts file, so the file that exports actually methods and functions that are used. But also on line 17, you have exactly the file name that we were testing locally when we were running pnpm pack method. If you get 405, make sure that your package is named properly. Once you publish it, your package is available on GitHub. You have info how to install it, how to add it to packet.json, you have information about the previous releases. On the right-hand side, you have readme as well, and link to repository. Let's talk about versioning now. The standard for versioning is the major, minor patch format. That translates to, let's say, major one, minor three and patch is zero. So, when you will be releasing a breaking change, you want to communicate to the user that they may need to update the usage of your library, and you do it by releasing major versions. And this is commonly known as the egg and chicken problem.

I didn't want to commit it to the repository. That's why I write to the file as a pipeline step and I have access to my secret here. There is the repository secrets. So I create this npmrc file. Install dependencies, run my tests and build the project, and then can publish, as I said, to my GitHub registry that includes my username as well.

When you run the pipeline, the output looks more or less like this. It is on line 12, you have your index.d.ts file, so the file that exports actually methods and functions that are used. But also on line 17, you have exactly the file name that we were testing locally when we were running pnpm pack method. Again, same as previously, it didn't work the first time. Didn't work the second time. When I was trying to publish to my GitHub feed, often, I was getting 404 or 405. And I figured out the way how to authenticate it, so as I was saying, .npmrc file needs to include the secret and correct registry URL. However, name of your package also needs to include your GitHub username. That was interesting learning. If you get 405, make sure that your package is named properly.

OK. So, once you publish it, your package is available on GitHub. You have info how to install it, how to add it to packet.json, you have information about the previous releases. On the right-hand side, you have readme as well, and link to repository. It's really nice, isn't it? So, as you can see here, there are different versions, recent version, there's alpha and so on. Let's talk about versioning now. So, standard for versioning is the major, minor patch format. That translates to, let's say, major one, minor three and patch is zero. So, when you will be releasing a breaking change, you want to communicate to the user that they may need to update the usage of your library, and you do it by releasing major versions. So, let's say bump the major number to two, you will have version 2.0.0. If you release this small change to your application, maybe just add additional helper function, you would just bump the minor version. So, 1.4.0. And when you work with patches, so, like the small fixes, maybe you updated readme or something like this, you would just update the patch version. However, when you work with the package, and you create the PR, you update the code, and you release this package, you would probably create just a patch update 1.3.1. And this is commonly known as the egg and chicken problem.

6. Publishing Pre-releases and Version Control

Short description:

When working with pull releases, it is common to add pre-release versions like alpha, beta, or RC to prevent publishing breaking changes. Despite this, it is still important to publish pre-releases for testing purposes. There are various tools available to help control versioning, such as package.json, Git version, GitHub actions, and tags. It is recommended to choose one and refer to the documentation for guidance. Additionally, it is crucial to provide clear installation instructions, contribution guidelines, and examples for users, who may be quality engineers or developers.

Because your PR might be, your pull request might be creating the breaking change for the user, or your pull request code might not be completed, might not be working as user would expect. But if they have in their package.json, version pinned this way, instead of my test helpers being pinned to version 1.3.1, they allow all versions above this version to be installed. So if you're introducing the breaking change, they would consume this code as part of installing dependencies. That's why when we work with pull releases, we would often use, we'll be adding, let's say, hyphen alpha, hyphen beta, or RC release candidate, to make sure we are not publishing real release, like the full release. And we market with either conversion is used in the project.

So you may ask, okay, so why do we even publish it if that could be breaking change? Maybe we shouldn't be publishing yet if we still work on pull request, if it's not merged. But in the same time, you want to be able to test it. You want to publish this pre-release alpha, and then you want to install it in another project. And you can use it by just adding alpha dot zero and npm install.

Another learning as part of this project was to find out that there's lots of tools that can help you with controlling versioning of your project. This can be done via package.json. There's an attribute version. This can be done by a Git version, actually a tool. This can be done by GitHub actions or maybe by the GitHub tags. There's lots of ways to do it. What I would recommend is to pick one of them and go into the documentation and figure out how to use it. I got myself confused a little on the way when I was working on it. So yeah, check documentation of the tool that you decide to use. And read me. So who is your user? Your user is another quality engineer and your user is developer. They need to know how to install your project, how to contribute to it and how to use it. So both helpers are available for them. So an example, how installation process and contribution guide. And that's all. I hope that you enjoyed this talk, that you learned something new. Maybe you will decide to take this learning away and build something for your team as well. And I hope that you will enjoy other talks at Test.js.

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

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
React Advanced Conference 2021React Advanced Conference 2021
19 min
Automating All the Code & Testing Things with GitHub Actions
Code tasks like linting and testing are critical pieces of a developer’s workflow that help keep us sane like preventing syntax or style issues and hardening our core business logic. We’ll talk about how we can use GitHub Actions to automate these tasks and help keep our projects running smoothly.
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.