Achieving A11y Automation Testing

Rate this content

Accessibility testing has come a long way in recent years. We'll dive into how EmberJS prioritized A11y with meaningful RFC's, Addons, tooling and docs. Most importantly, we'll discuss how these successes can be applied to your very own apps be they Vue, React, Angular or anything else!

27 min
15 Jun, 2021

AI Generated Video Summary

This Talk discusses automation testing tools and strategies for accessibility. It highlights EmberJS's approach to accessibility and the efforts of the developer community. The importance of prioritizing accessibility and using tools like Ember A11y testing and Axe-Core is emphasized. Integration with React, Vue, and other frameworks is made easy with NPM packages. The Talk also emphasizes the value of manual testing and user evaluation alongside automation testing.

1. Introduction to Accessibility Automation Testing

Short description:

Hello, everybody from around the world attending TestJS Summit 2021. I would love to speak to you today about some automation testing tools and strategies that everybody here hopefully can use starting today, if they wish to, around the topic of accessibility, specifically accessibility automation testing, this is a very exciting topic for me. My name is Ava Gayde-Rohten and I am a lead full stack software engineer at SkillsEngine where we build apps in rails and in EmberJS. So there's plenty of JavaScript, which is where I put my focus. And that focus is mostly in the framework of EmberJS. We will in this presentation, talk a little bit about EmberJS and specifically how it tackled accessibility, I believe it did a really good job and I'll get into how and why. And then we will cover some tools and strategies for everyone, regardless of what you're using, you might be on react, maybe you're on Svelte or Vue, for example, doesn't matter. We'll talk about those things. We'll also talk about how to automation test some of that, as well as generally taking ownership and being able to contribute perhaps back to some open source projects or the framework that you were working in. Ember has been embracing web standards for some time now. We like to say that we are very HTML first. We focus on W3C recommendations, MDN patterns, and HTML first allows us to inherently be very cognizant of accessibility. So let's get this out of the way. This is an important, I guess, let's talk about why accessibility is important. Not just some stories that I've had. People with disabilities are the world's largest minority.

Hello, everybody from around the world attending TestJS Summit 2021. I would love to speak to you today about some automation testing tools and strategies that everybody here hopefully can use starting today, if they wish to, around the topic of accessibility, specifically accessibility automation testing, this is a very exciting topic for me.

I want to get one thing out of the way. If you see in my slides, or I say out loud, A11y, which you can see on the screen right now, that simply means accessibility A11y accessibility, they are synonymous. Brief explanation of why that is. There are 11 characters between the A and the Y in accessibility. And if you've been working with internationalization in the past, you might be used to seeing I18N it's the same thing I18N for internationalization and A11Y for accessibility. But I digress.

My name is Ava Gayde-Rohten and I am a lead full stack software engineer at SkillsEngine where we build apps in rails and in EmberJS. So there's plenty of JavaScript, which is where I put my focus. And that focus is mostly in the framework of EmberJS. A bit of this talk will be in EmberJS, which I imagine not too many people here are using, but I would like to share some of my background in that and some success story. And then we'll get into how to apply that to what it is that you are working on.

So, as I just stated, we will in this presentation, talk a little bit about EmberJS and specifically how it tackled accessibility, I believe it did a really good job and I'll get into how and why. And then we will cover some tools and strategies for everyone, regardless of what you're using, you might be on react, maybe you're on Svelte or Vue, for example, doesn't matter. We'll talk about those things. We'll also talk about how to automation test some of that, as well as generally taking ownership and being able to contribute perhaps back to some open source projects or the framework that you were working in.

So last year, 2020 EmberConf, I spoke virtually at that conference about a slightly different success story around accessibility. That one was about how we were able to make a feature that we were shipping in our application even better by making accessibility a priority, we were able to have engineering, QA, design and product all much happier with the thing that we delivered, we were able to deliver some automated tests around something that was clicking draggy. And that's very difficult to write automation tests around. And because we added in accessibility, we were able to test that instead. That's a different topic for an update, but I have had multiple success stories, not just in Ember, but in accessibility as well. And I'll talk to you about some of that today.

Ember has been embracing web standards for some time now. We like to say that we are very HTML first. We focus on W3C recommendations, MDN patterns, and HTML first allows us to inherently be very cognizant of accessibility. So let's get this out of the way. This is an important, I guess, let's talk about why accessibility is important. Not just some stories that I've had. People with disabilities are the world's largest minority.

2. Accessibility Made Easy

Short description:

Accessibility doesn't need to be hard. Getting started, diving in, making some of it happen doesn't need to be hard. It can be automated and make your work easier.

There are some common things that go along with that. You might be able to argue that if you make apps that target people who have disabilities as well, you get more customers and more innovation in your product. And those kinds of things are very true. Those are legitimate and those are valuable. But what I want to talk about is a little bit different. And I wanted to also say that people with disabilities is a broad term that speaks to many different things. It includes, but it's not limited to visual, auditory and motor disabilities as examples. But what I want to tell you all today is that accessibility doesn't need to be hard. Sure, doing it perfectly, or even doing it extremely well. That's hard. Getting started, diving in, making some of it happen doesn't need to be hard. It can be automated and furthermore, it can make your work that you do on a day to day even easier.

3. EmberJS's Approach to Accessibility

Short description:

EmberJS embraced accessibility through core support and the efforts of developer Melanie Sumner. An accessibility working group was formed to address existing pitfalls, with discussions and issue logging on GitHub and Discord. The community worked on solving issues, creating guides, and documentation. EmberJS also has an Ember accessibility specific GitHub organization and add-ons to extend accessibility work. Some work made its way into the core Ember framework. Two major tools for accessibility testing are Ember A11y testing for automated tests and accessibility audits.

So how did EmberJS embrace accessibility? I like to introduce two friends of mine. These are the mascots for Ember. On the left we have Tomster and on the right we have Zoe. And they are wearing their accessibility shirts very proudly. We have some core support in EmberJS around accessibility and this makes the biggest difference. I like to call out a wonderful developer by the name of Melanie Sumner. She is a senior engineer at LinkedIn. She has her hands in the pots of a lot of standards that are written for the web, as well as being a core team member, giving us first-class support for things that are important to her, such as accessibility. This means that in EmberJS there is a deep respect for accessibility. One of the things that Melanie Sumner was able to put together was an accessibility working group where we discussed some of the accessibility pitfalls that were currently existing, and we were able to get together in an open source way, where we were logging our notes up on GitHub, and we were able to hop into Discord, schedule meetings, talk about things, go offline, be asynchronous, and all the great things that working open source will give you. It was really great. We were able to address some project issues, whether they were logged by the open source community or by us, as we identified things that were just fundamentally lacking.

Part of the thing was that we acknowledged that at the underlying framework level, every app that is built with Ember, if there are pitfalls, then all these apps could potentially have pitfalls. And so we've worked to address those things. So we worked with issue logging and addressing those issues. We worked with writing up some RFPs, which is a fairly invested way of basically promising and explaining how you're going to solve something that's neither here nor there. Ultimately we got to the point of being able to solve some of these issues, assigning out these tasks to various different people in the community. And we worked very heavily on guides and documentation. Every framework has a section of documents that will explain various different things and each one I've noticed has at least something on accessibility. I'm very proud of what EmberJS has put together around it. There's also an additional site that I helped with writing some articles around and it's about Ember component patterns, which is a way of saying patterns and anti-patterns just like MDN does, the Mozilla developer network. And we're able to focus in on not just teaching how to write components that are HTML first W3C compliant, but are accessible as well. A lot of great things there. Along with having first-class support, there is also an Ember accessibility specific GitHub organization, which was a great place to house a lot of this work that we were doing and a lot of the add-ons, which is what we call plug-ins or tools that can extend an Ember application to make a lot of the work that these different apps probably need to do around accessibility much easier. I also want to point out that a couple of these managed to make its way into the core Ember framework after much discussion within the community. That was great as well.

So getting into the good bit, code. We have two major tools that help specifically with accessibility. The first is in tests. So writing some automated tests, we have an NPM package called em, sorry, it's Ember A11y testing, which will allow you to render out an entire page or a component, and then run an A11y or accessibility audit over that.

4. Accessibility Testing Tools and Strategies

Short description:

Automation testing tools like Ember template Lint and Axe-Core can help ensure accessibility in your code. Prioritizing accessibility is crucial and can be done by discussing it in your workplace, trying out new things, and contributing to open source projects. Axe-Core, an NPM package, is a powerful tool for detecting accessibility violations. It covers a significant portion of accessibility rules and can be easily integrated into your development process. The browser extension and framework integration make accessibility testing even more convenient.

This is great because you can write some green tests, and then if a update happens in the future, or somebody goes in and touches some code, it can fail your CI builds if those are those pages or those components are no longer accessible like they once were. And they can act as great checklists as well for the developer.

It's also Ember template Lint. This goes alongside things like ESLint, which will let you know when there are some warnings or errors in the code that you are typing. This one focuses on the templates, the HTML, and will let you know in your code editor as you are typing something like, hey, I have an image tag and I forgot to write an alt attribute. When set up correctly, you can also have this fail in CI as well, as it goes through and lints all of your files.

So that's all great. Yay, applause for Ember. What we're here for is how to use these in other frameworks. How to take these tools and strategies and apply them to Vue, apply them to React and Svelte and anything else. So what's the first step? The first step is realizing that we need to prioritize accessibility. That means if you're in a nine to five, maybe you need to talk about it in your workplace with your team, with your product manager. Maybe it just means trying out some things. It also means in your communities, whether they are in person or online, open source projects you're really passionate about, or the frameworks themselves that maybe are lacking in certain areas and you can contribute to. That's why I'm here today is to talk about it, talk about prioritizing accessibility, talking about why it's important and spread the word a little bit and everywhere we can do this is a step in the right direction.

In the code again, there is a wonderful tool. It's an NPM package that was published by Dex systems called Axe-Core. This is made by a group that works on a lot of the standards around the web that are able to declare what are some warnings and violations for accessibility, and then to write some automation testing around it. Some of these tools can cover up to 50% of the accessibility rules that are out there. And that might not sound like a lot, but in some ways it really is, and it's a great start. Getting started with this kind of a tool is as simple as NPM installing it, running Axe, and then seeing what violations it has found. Now this is a core tool that is most often used to power other tools. And it's the foundation of so many other things, such as the browser extension. Browser extension is incredibly easy to get up and running with no matter what browser you're running. This is also maintained by DeX systems themselves. So it's got great support. And it can let you know exactly what it found on your fully rendered page or app and what the priority is in fixing it as well as maybe how to fix it. This is particularly great, not just for engineers, but QA, maybe design or product to log these issues and whatever kind of ticketing system you might have, if that's relevant to you. Now framework integration is where it gets even more exciting. If you're using Svelte, congratulations, you already have accessibility built into that framework.

5. Integration with React and Vue

Short description:

If you're using React or Vue, it's as simple as installing an NPM package. Vue use, Vue acts and you're done. The framework integrations do the heavy lifting of de-duplicating warnings and intelligently re-checking for new warnings.

It should be already outputting to your browser dev tools, I believe some of these kinds of warnings. But if you're using React or Vue, it's as simple as installing an NPM packets for both of them. Perhaps limiting down to just your development environment or maybe a staging environment, if that is good for you, but it's just these simple lines of code, this is it. Vue use, Vue acts and you're done. Now, suddenly you have something that is using ax core to send to your browser dev tools with. Very clear understanding of whether something is critical, serious, or moderate, a URL of how to figure out what to fix, et cetera. What's great about the framework integrations is that not only are they that not too much work, but they do some of the heavy lifting of de-duplicating some of these warnings and hooking into the underlying systems that say, Hey, I have a component that just re-rendered and update was fired and they are able to intelligently re-check and see, Hey, is there something else to be aware of? A new warning that I haven't already put into the developer tools.

6. Linting, Automation, and Testing Frameworks

Short description:

ESLint plugins for Vue.js accessibility and JSXA11y provide direct warnings in your code editor, making it easy to make adjustments and improve accessibility. These developer tools are usually free to use and have a significant impact on the accessibility of your application. For true automation, you can use Axe core by plugging in just axe and awaiting the results. This allows you to verify accessibility within your testing environment and end-to-end testing frameworks.

Now, as far as Linting goes, there is ESLint plugins for Vue.js accessibility and JSXA11y. I'm sure there are others as well, and these are able to tell you directly in your code editor of choice, just like anything else in ESLint, Hey, something you just typed or something in this file has a warning and it's right there, you can see it and edit that file in order to make your adjustments and then see those warnings go away. It is so satisfying and to be able to do this for accessibility. It's just an easy win. It's like almost no reason not to do this. These are developer tools, which means that they are. Usually free to put into your application aside from a little bit of NPM install time, because these don't even hit your users, but the effects of the things that you fix will, let's talk about automation. I would argue that a lot of things I just talked about in some ways are kind of automating. It's not manual effort to go through and find some of these things, but you know, if we want to talk about some true automation, maybe you're using just. Axe core can plug in just by using just axe, and then you can await axe, send us some HTML and then expect it to have no violations, it's as easy as that. Once you have that in place, you can verify that within CI within your testing environment, maybe within some component code that that component or whatever it is you're working on is accessible if you are using end to end testing frameworks.

7. Automation Testing and Community Contributions

Short description:

There are plugins and libraries available for automation testing in different frameworks, such as WebDriver IO and cypress axe. The Vue A11y community is a promising resource for accessibility tools and contributions. While automated testing is valuable, it should be seen as an enhancement, not a replacement for manual testing. Real user testing and manual evaluation are essential for ensuring usability and accessibility. Today, we discussed the importance of accessibility, success stories, making it a priority, and the availability of AXe Tools.

So things that are slightly separated from the framework itself that are rendering full URLs, perhaps on a staging environment or a QA environment, for example, perhaps WebDriver IO. There is a plugin for that axe core WebDriver JS. Or if you are using cypress axe, there is a wonderful library for cypress. And it's as easy as this. I'm not cutting out very much code on these slides. It's this simple.

As far as communities go, as I mentioned earlier, a lot of frameworks have some great communities, some great documentation that are starting to come up. One of the most promising ones that I have seen so far is the Vue A11y community. They have a beautiful, very accessible website. It's great to start there with an accessible website where they have so much potential for posts, recipes, tips and tools. Their tools are the most built out, much like we had Ember addons that I was showing earlier. There are some Vue tools like Vue Skip To or Vue Announcer that can help you handle some of these things that are a little bit more difficult to pull off without these addons kind of lending you a hand. This Vue A11y community is like begging for some more contributions from the open source community. I would say if you're into Vue or curious about Vue and accessibility, it's open source. Hop on there, take some of the pages that are placeholders right now that are just begging for some recipes or best practices around accessibility. Write out some of those open support requests. The community will thank you, I'm sure.

John at Sparkbox said, automated test as an enhancement, not a replacement for manual usability and accessibility testing. It's important to keep in mind after everything I just said and how excited I am about automated testing for accessibility to know that it's impossible to really get all the way there, just as it's not reasonable to expect 100% test coverage on any application you're writing tests for. There's going to be some real user testing that you will have to do. Some manual walking through the app and seeing how usable and accessible it really is using screen readers. Using your keyboard to navigate through your applications. Perhaps the next time that you write a component just see if you can tab through it. It's a good place to start.

So today we talked about accessibility. We talked about why it's important, and some success stories about how Ember was able to do it, how some other frameworks are starting to do it as well. We talked about making accessibility a priority in your workplace or your community. That might mean a framework that you have a lot of passion about, or it might mean the team that you work with at your 9-5. We also talked about some AXe Tools that are available for practically any environment, and if it's not available for yours, there's Axe-Core. You might be the person to make that new NPM package that is powered by Axe-Core to make something wonderful happen.

8. Leaving a Personal Request and Getting Started

Short description:

Finally, I want to leave you with a personal request to hire someone different than you if you have the means to do so. Your team, company, future employees, users, and I will thank you. Where do I start? Talk with somebody on your team, whether it's a 9 to 5 job or a personal project. Make it important, log issues, and start talking about accessibility. Get started with your main tool or framework, followed by accessibility or Axe. There are alternative tools for different frameworks like Angular.

Finally, I want to leave you with a personal request from me that is indirectly kind of related to this, and that request is to hire someone different than you if you have the means to do so. Your team will thank you, your company will thank you, future employees will thank you, your users will end up thanking you, and I will.

I want to say thank you for watching and joining me today. That is amazing. I do have to say that I was expecting the ones that were in the lead to maybe be in the lead but I did not expect it to be this close across the board. I think my main reaction is that there are some places where it is legally required. People have to adhere by a standard, a particular quality of reaching some like accessibility level, but a lot of the time it is in the back of my mind. I sure wish we could do accessibility. That is part of why I wanted to do this talk.

While you join me on stage, the camp that says it is unsure where to start is pulling ahead. That is going to be my first question to you as we go into our Q&A session. Where do I start? I want to know more. Where do I start? Absolutely. I hope that this talk was able to provide a little bit of that. But where you start is talking with somebody on your team. Again, whether that is 9 to 5 or some personal project that maybe it is just you or it is just you with your friends or open-source thing. It doesn't matter. Just talk with people. Make it important. Log some issues. Just say like, hey, I don't think this was going to work for somebody who is using a screen reader. Just log those issues. Start talking about it. In terms of meaningfully taking some action and doing some code, basically, getting started with whatever your main tool is, your framework, followed by accessibility or Axe, you're going to find these tools that I described and some other tools that I didn't get a chance to mention, like the ones for Angular, for example.

That's good. We actually had someone that said, that wanted to know if the ember tooling was a must, or if there's any alternative to the ember tooling. I can see a little ember behind you, so I know you're an ember fan. Yup. Guilty as charged. I have been doing ember for far too many years now, and just along with that, I've realized that I have some success stories to share, some things I'm really proud of, but what I really want to be able to share is how these things can be applied in other places.

9. Accessibility Tools and Convincing Managers

Short description:

There are tools available for Svelte, Vue, React, and Angular. A linter can catch some accessibility problems, but not all. It helps with basic issues like missing labels and accessible text. However, it won't cover all scenarios, such as keyboard navigation. Convincing your manager about the importance of accessibility can be done by using similar arguments as for automation testing. It's crucial to emphasize the impact on the bottom line and the relevance across different industries.

So I hope that I was able to show some tools that are used for Svelte, Vue, React, and there are also ones out there for Angular. I just didn't want my slides to get too long, but there are tools out there for anything that you're using. That's good. That's really good, especially since accessibility I think is so important.

There's some other questions in here, so I'm going to go through some of them. For example, would a linter be enough for basic accessibility testing? Or are most violations found after deployment in a more end-to-end style test? That's a great question. For accessibility problems, a linter will catch at least one of the cases, one of the types of problems that you will have. probably two major cases. In the same way that will a JavaScript linter catch all of your JavaScript errors? No, but it will catch a certain case of them. You will still have undefined problems. Of course we're not talking about TypeScript, but you'll still run into other types of issues in the real world. Having a linter will allow me to realize, oh, I forgot to add a label around my input. I forgot to put accessible text on my image element. But it will not help somebody who is actually trying to flow through your entire form with the tab key and fill out everything just solely with a keyboard.

That makes a lot of sense. That makes a lot of sense. There's a lot of questions. We won't be getting to all of them. I just want to remind everybody, Ava's going to be in her speaker's room afterwards, so you can ask the questions that I didn't get to in In the meantime, I think one of the questions says, how do I convince my manager that accessibility is important? If that argument is, if users work in a restaurant, then accessibility is not an issue. And I think this is one of the most common sheets I've seen. Users work in some sort of whatever environment, be it the restaurant or you name it. It's not an issue. How do I convince my manager? There are several answers to this, but I'll try to get through them very quickly. You can use similar arguments that you have used for doing automation testing to begin with. You could argue very quickly that we don't have time for automation testing. Let's just keep shipping out code, but ultimately it hurts your bottom line. And you can prove that mathematically if you really work at it and try to find those arguments. Also, these kinds of things do apply to every different type of vertical, every different industry. For so long, we heard that mobile app development is not important.

10. Importance of Mobile and Diverse Hiring

Short description:

We realized the importance of mobile over time. Hiring people different from yourself brings diverse perspectives, influencing culture. Culture is a crucial aspect of this conversation.

We don't have to worry about mobile. And then over time, we realized that was not the case. It's true that we need mobile for almost everything.

Lastly, I want to say that if you can hire people that are different than who you are, that was the last thing I said at the end of that talk, you're going to wind up with even more people with different perspectives, with different needs and desires and influences. And you might suddenly realize that your culture will change before your very eyes. I love that. I love that bit about culture. I think it's a really important piece of where this conversation starts, because it's one of those conversations that you'd hope it never comes up because you're doing the right thing.

Thank you, Eva, for the Q&A session and for your thought. It was really good. I think I got through 20 percent of your questions. So whoever had questions that I didn't get to, please join Ava in the speaker's room on spatial chat.

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
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
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
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.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
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.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.