I have been in the automation space for a very long time and have seen some really amazing ideas and some really awful ideas when it comes to automation frameworks. The one thing that has helped me along the way is figuring out if a framework can handle the “login test”.
Can it log in to your website? Simple enough… right?
Before we start I want to make sure that we all have the same concept of a Login test. It should have the follow characteristics.
- Start from HTTP url. On a stage or production environment it should handle the 302 to HTTPS.
- It should have a username and password items. This could be done within an iframe or separate window if you’re using a 3rd party service like OKTA
- It should in the positive case redirect to a new landing page. In the negative case it should error and show the error that you can access.
Hopefully none of this should be controversial right?
If you’re unsure why the follow should be important to be able to handle let’s break down a high level what is happening in the browser.
With CORS, HTTPS, Same site origin policy, mixed-content all in the space, there are loads of areas where just injecting JS into the page to control it will be up against a sandbox of sorts. If you’re ever wondering why it’s hard to do single sign on as part of your testing then one of the above is likely to be blocking your framework. Also, don’t fall for “logging in is an anti-pattern” some groups push to cover up their inefficiencies in their product. Doing it on every test is an anti-pattern. Making sure it works is a normal thing to do
When doing a login page, it is important to have defence in depth. We need the server to be able to handle the login
POST from the browser that the information is correct or if it is incorrect that it doesn’t give away too much info to allow a hack.
On the front end you need to have the usual forms and you need to make sure that have the user inputs are real. In browser nomenclature that means
event.isTrusted will return
true. If it returns
false then you know the clicking or typing has come from someone calling
If you’re after a use case for this? Say someone creates a phishing page for your site to get logins but doesn’t want to be caught out. They could take your details and then in a hidden iframe be passing the details onto the real site, after storing your login info.
The main reason this all matters is there are a number of popular test frameworks out there that can’t do the above. They even tell you that the following is an anti-pattern. As mentioned earlier it’s only an anti-pattern if you do it too much.
You can spot these tools by their inability to work with real browsers on desktop or mobile. If you’re not using what your users are using it’s likely to cause bugs that you’re unaware of until it’s possibly too late.
I recently discussed this at Selenium Conf. If you missed it then watch it below