Chai Assertions and Accessibility Testing with Aparna Gopalakrishnan

Five, four, three, two, one.

Drop that.

Welcome to the Test Guild Automation Podcast. We're all getting together to learn more about software testing and automation with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Automation Podcast. Today we'll be talking with Aparna Gopalakrishnan about the BDDTD Node Library CHAI as well as web accessibility testing and and probably much, much more. Aparna has a bunch of experience. I believe she holds around five international certifications with consulting experience with some of the world's top companies around the world, helping them with their test automation and BDD efforts. So really excited to have her. She was really skilled and passionate about learning new tools and technologies and applying them in the real world. And that's why I'm excited to have her join us today. So listen up.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Sauce Labs. Their cloud based test platform helps ensure your favorite mobile apps and websites work flawlessly on every browser, operating system and device. Get a free trial. Visit testguild.com sourcelabs and click on the exclusive sponsor section to try it for free for 14 days. Check it out.

Hey Aparna, welcome to the Guild.

Thank you Joe. Thanks for having me here at Test Guild.

Awesome to have you. As I mentioned, I gave you an intro but for the folks that don't know, is there anything else you want folks to know?

Oh yeah, sure. So my name is Aparna. I work for Wipro in London. I'm a test automation consultant, specialized in creating frameworks and designing solutions on web API accessibility and visual test automation, mainly on Java and js. I'm also a trainer and do provide trainings on test automation and bdd. I would like to learn new tools and technologies and would like to share what I learned back to the community as well.

Very cool. So I'm already off topic. I didn't know you were a trainer. So is there any issues you see over and over again as you're training people that they struggle with with automation?

Yeah, so I do, I mean I have done trainings in the organizations before. So like we have training programs for the beginners who joined to the company like freshers. So we I trained them basic automation like Selenium and then introduction to bdd so they get skilled themselves before they join the project. And yeah even there is a program called Digital Academy Trainings that is focusing mainly on the tools and technologies that are used in the projects.

Very cool. So what caught my attention Is I believe you recently did a online course for Tessa Automation University on Chai assertion. So I guess to start off, what is Chai? And I know sometimes I hear Chai or Mocha and it seems more like a developer friendly tool. So I guess before we get into all that, what is Chai all about?

Chai is basically an assertion library. So we all use assertions in our test. Basically assertions are just flowing before asserting or if you are logging into an application and then you want to ensure that you have logged in, so you write some conditions like whether the expected output and the actual value are same. So Chai is a library which provides certain functions to do assertions in your tests.

So what language is this for? Is this for JavaScript that you would use Chai?

Yes, that's a JavaScript testing assertion library.

Cool. So I know there's also one for Mocha. Is there any reason why you chose one over the other or is it just what the company was using?

So Mocha and Chai are two different things, but Chai can actually be worked along with mocha or any JavaScript framework. So both are different. It is just for assertions.

So for someone familiar with Selenium, is it like a Hamcress matcher type library?

Yeah, so yeah. So we can. So if you, if you take a Node JS framework, Node JS has its own assertions, but Chai is giving a lot more options for doing assertions, especially if you are using any TDD or BDD based framework like Mocha. Mocha is a JavaScript BDD framework. So Chai is giving some certain assertion options which can be used with mocha or any JavaScript framework. So it comes up with three options. One is like normal assert, which is. Which is very similar to a Node JS assert statement which just takes actual value and expected value and then compares and gives the results. But it has also got other two options called expect and should, which is the TDD or BDD format of writing the assertion. So we can actually append the English like statements to be equal to this value. So it's more of a English and then we can actually use it with any BDD framework. So PDD is more of a given when done in plain language. Plain English language expressions for writing the test. Right. So Chai can be used along with those to complete the assertion format.

So what are the Chai assertions give you at the built in ones for Node JS and Mocher don't give you like what is the assert? I guess can you give an example of each one maybe start with the assert.

So CHAI is coming up with three options. One is assert and then expect and then should. So if you look at assert, assert is normal node JS assert. Let's take an example of logging into an application. Say for example, we are logging into a Google. So when I give my username and password I expect aparna, my name will be displayed on the screen. So expected output is aparna and actual value. In case if I'm not giving the right input, I'll be getting an error. So assert. The syntax of assert would be something like assert and then actual expected. So if there is any error in the assertion, then there will be assertion error and we can actually look at the error log and see what the error is. So it is normal like a node JS assert.

Okay, so what about the expect assertion?

Expect has a lot of options. So expect is keyword which can be used along with plain English which forms a BDD format for your assertions. So for example we have a, we have a name which is a string and which we wanted to verify that is a string. Then normal case we will be just doing that assert. If we are using simple assert, then that will be like assert and then assist string. I'll just take one example, this example like logging into this application. So we have a name which we have received from logging in and then we will assert that name as equal to string. But in expect, what we will do is we, we will have a variable and then we will actually do expect. Say for example name is our string. Expect name to be a string. So when we read that complete statement, it would be something like expect name to be a string. So it is, it gives a complete understanding what does that statement all about. And if there is any error we can also extend the assert statement with some error message. Say for example expect name to be a string and then we can append a message if there is any assertion failure. Name should be a string. So if there is any assertion error, then this message will be thrown in the assertion error. So that way we can make it more understandable and meaningful for the assertion scenarios.

So how about the should assertion? How does that work?

Should is another form which is slightly different from expect. So the way it works is expect. Whenever we use expect, expect is the first keyword that we use expect and then followed expected and actual values that we wanted to compare. When it comes to stood, should will be something like what object that we wanted to compare that object dot should and then we Will we will have the condition say. For example, if we are comparing this name should be a string, then how we will be doing is name dot should dot be a string. So you see a difference there. In expect we will use expect as the first keyword and expect name comma string and then we write what is it? And when it comes to should, we will say the object dot should dot be a string. So slightly different in terms of implementation but in other ways. The purpose of assertion or like whatever we are what we wanted to do with both the keywords are ultimately the same. So when you look at the differences between expect and should is this like one one requires the object to be used as a first and the other one the keyword will be used as a first.

So if you're listening to this, it may be hard to follow along or visualize it. So what's awesome is you can actually check out the whole course for introduction to CHAI Assertions at Test Automation University. So definitely check that out. Is any functionality in CHAI that you think most people don't know about or don't use enough of?

Yeah, like most of the people use equal access, probably not equal, but there are a lot of other things like throwing exceptions like should throw, should, not throw. We can handle exceptions as well. Throw to this CHAI assertions which not many people are aware of and using it.

Very cool. So I thought we changed gears. Like I said, you have a lot of experience with a bunch of different things. I think I saw that you're speaking at another conference coming up about accessibility testing. I guess at a high level for folks that don't know how. Would you explain what is accessibility testing?

Basically accessibility is more of a practice which we need to ensure the website that we are building is accessible for everyone. So everyone is inclusive of the people who are differently abled or disabled or people are having problem with vision, hearing impairments or memory problems or mobility problems. So we are in a digital world and many people actually use a lot of digital devices.

So we need to ensure that whatever we're building is for the people who are having these accessible problems. So web accessibility is a practice to ensure that web is accessible for everyone.

Are there any guidelines you could recommend that people could follow to help them maybe with their accessibility testing?

Yes, there are. So there are some standards called WCAG Web Content Accessibility Guidelines, which is.

Introduced by the group W3C. So they have got a lot of a bunch of standards which are falling under WCAG 2.0 and 2.1 and 2.1 is the latest one which was released last year. And the website that conforms to point one conforms to point zero as well. Like it's a backward compatible.

Guidelines. So as per law now.

In almost all the countries are actually making it as a mandate that every website has to have this web accessibility checks done. It should be tested. So we have to follow these guidelines while building.

The website. So from design phase we need to consider this so we can test that well and deliver a more accessible product.

So I would think this be more of like an exploratory type testing effort. But can you use any tools to kind of help guide you as you're testing to make sure you're building an application that is accessible?

Yes, there are many tools starting from screen readers and through APIs for automation. And even if we do not have any tool, we can still test it using our keyboard. So if the website is built with all the accessibilities, let me navigate through keyboard, it should actually go through all the links on the page. So when you use a screen reader and when you use this tab, it actually reads out what is on the screen for you. So many people who are having visual impairments would go with the screen readers. And there are some tools like browser plugins where we can use this, we can test the color contrastness of the application. And There are some APIs for test automation. So if you have a functional test framework which does your functional test automation and these APIs can actually this accessibility APIs can be integrated with those and you can write accessibility test cases and validate that as well. So Axe is one of them. Axe Core is a product from Deque which comes up with three different options. One is as a browser plugin, another one is an API for web accessibility testing. And recently they have launched for mobile application as well.

How does. If someone's an automation engineer and they're writing selenium tests for functional automation, is there a way you can modify that to actually do some sort of accessibility testing as well? Or do you separate out the test for different domains?

Tests are different.

And you cannot define accessibility test case should be like this and like any other testing. Like we can, we can actually do a proper estimation of.

Like if you get a business scenario, these are the test cases. Like we can actually define that. But accessibility is not something you can define in a box because every, every page is different and every people are different. So and not all the guidelines in one page have to be satisfied because that page, say for example, if you are not having A video on a page, you may not see that rule getting passed. So there is a rule in WCAG that for any video there should be captions available. So suppose a page is not having a video, then that rule might not be passed. Right? So you will not see that result. So that doesn't mean that it is not following that guideline, it's just that it is not there. So it doesn't want to test. Of course, the accessibility test cases have to be different from the functional test cases. For every domain there has to be different set of test cases just for accessibility. We cannot define or we cannot limit. These are the test cases that have to be part of accessibility.

Awesome. I know you mentioned you also did visual validation testing. Can visual validation testing be used to maybe as an after effect? So you run a test, you have all these screenshots and then you can just look through the screenshots and just check for maybe any sort of violations that you may see that may be caused by something not being accessible.

Yes, to some extent we can prevent many accessibility issues through visual testing as well. I'm not saying 100 percentage, but yes, to some extent because accessibility is part of usability. Right? We can define accessibility also as a usability of the website for a set of people. Right? It should be accessible. So when we test the user experience testing using visual testing.

We are ensuring that what we see on the application is actually right. As we expect.

When we do functional testing using Selenium or qtp, maybe we'll be just comparing the DOM elements and then we expect something is there on the screen just by doing assertions with a DOM presence of that element. But when we actually do visual testing, we are seeing whether that element, for example, if you are logging into an application and the submit button is not overlapped with the password field, we are passing the scenario, the application is visually correct. So that way, to some extent, yes, accessibility is also. Accessibility can also be tested with the visual testing. Very, very small percentage. But yeah, it is actually helpful.

So do you have any resources you usually use for either CHAI or web accessibility testing if someone want to dive in a little bit more and learn about them?

Oh, reference, we have like on especially on Chai, we have Chai's official webpage which has got enough information on the implementation of all of their APIs. So that itself is a good difference. And accessibility, if you are looking at any specific tool, especially the axe, because AXE is one of the best tool that I've seen, which is covering almost.

A good coverage of the rules if you look at the accessibility guidelines so and it gives manual as well as the automation feasibility especially they have come up with this mobile automation mobile application support as well. So it is something which is a good reference to go and see the dequeue axe page they have the implementation and the steps.

To follow for testing accessibility and axe core is the engine which has got different integrations, different framework integrations. So dequeue axe page will be a good reference for accessibility.

Before we go, is there one piece of actionable advice you can give someone to help them with their either CHAI or accessibility testing or even automation testing in general and let us know the best way to find or contact you.

So firstly on assertions the advice would be any for any test automation we should have assertion in place. I have seen.

People are doing automation just not validating what they expected to see. So assertions are very important and everyone needs to understand assertions and that has to be part of.

Your framework or your test automation script and chart is a very good, very beautiful assertion library which can be used along with any of your JavaScript framework which can be Mocha or WebDriver IO or any normal JavaScript code. And on to the accessibility part. Accessibility is a very powerful topic in today's world and it's everyone's. We have to take it as a personal responsibility to test and make sure that what we are building is for everyone. So it is not just following any law but it is a social responsibility responsibility that we need to build something for everyone to use. Because web is meant for everyone. So it's our responsibility to do that. It's for everyone. So I'm on Twitter so my ID is Aparna Aparna2019 and I'm on LinkedIn as well. Aparna Gopalakrishnan so yes, I'm happy to connect through these channels. Any questions or any queries on any of these topics. I'm glad to help.

Thank you Aparna for your automation awesomeness. Thanks to everything value we covered in this episode. Head on over to testguild.com a likeautomation274 and while you're there make sure to click on the Try it for Free Today link under the Exclusive Sponsor section to learn all about Sauce Lab's awesome products and services. So that's it for this episode of the Test Guild Automation Show. I'm Joe. My mission is to help you succeed with creating edge and automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Automation Podcast. Head on over to testguild.com for full show notes, amazing blog articles and and online testing conferences. Make sure to subscribe to join the Guild and continue your testing journey. This has been a Joe Calantonio production.