Now I got a question for you. This test over here, if you look at it and analyze it, do you believe this test is atomic? At first glance, this test might actually look atomic, right? In that it's signing in, validating that we were able to sign in and then it adds an item to a cart and asserts that an item was added to a cart. It's close to being atomic, however it's not actually atomic. The reason why it's not is because it has to login and validate that we have successfully logged in. There is no reason why we can't test the UI login in a separate test and ensure that works and then afterwards, what this test really cares about, what it actually wants to test is this portion right here. And so we can save time and stability by performing these interactions without using the user interface.
Atomic tests can come in many forms. Some of them can be extremely simple. For example, when we used to write automated atomic tests that click links, we actually have a wasted action and a wasted validation in that we need to click a link and assert that the link goes to the right location. What we're actually interested in is the Ahrefs attribute of the link, which we could easily validate in this manner, making our test faster and less brittle.
Let's go ahead and take a look at our first web application, which is going to have an HTML web form, and we're going to be able to log in to this HTML web form. But instead of using the UI, which is not efficient and not atomic, we're going to be able to make a web request that's going to end dropping a cookie in our browser, and then we're going to be able to bypass the log in without interacting with the UI. If we come to this application, there are many tests that are here, but I'm going to focus on one at a time, just to give you a better understanding. The very easiest test to understand, which is the positive test case, is going to be this test case here called Redirects to Dashboard on Success.
This is the very positive test case where we visit the login page, and by the way, you can see our application on the right hand side, if you're not familiar with Cypress. It displays the test execution on the left, with the actual application on the right, and if you did want to explore the application in another browser, you definitely can. Here it is, and it performs all the same exact operations, but with Cypress, for example, it's very easy in that you can see what the test is doing and then see the actual application on the right hand side and even interact with it if you wanted. You can see that the very first step that this test does is it visits the forward slash login of our application that is on local host 7077, and after that, it performs the standard operations that you would expect in order to actually be able to log into the application, right? So it's going to get the username and type in Jane Lane. It's going to get the password field and type in password and then it's going to submit the form. Once the form is submitted, you can see we do a couple of assertions. First, that the dashboard page is there, right? So our URL includes dashboard forward slash dashboard. So that means that we were able to successfully log in. Second, we get the header and assert that it contains Jane Lane. So almost checking not only that we're logged in, but that contains the right user and we get the cookie that corresponds to our login and make sure that there is a cookie that exists. So take a look at the application tab here and in our cookies. Currently, there is nothing available here. I've cleared it. But if we rerun the test, and of course, as I mentioned, it does interact with the application actually logged in. You can see that now there's a Cypher session cookie that's dropped, hence why we are able to log in through the application. The challenge with this test is that, again, it's not atomic, right? In that it does interact with this login form, and then it logs in, and then it validates that we're logged in.
Comments