Hey Y’all,

Today we will talk about an exciting topic (very briefly though).

How does one write a proper automation test?

Actually, this question has more than one correct answer so we will not start talking about all the different approaches, but stick to the “Set in stone” guidelines:

1. Do not duplicate your code! think of a scenario in which you have written over and over again a simple transaction (code) and duplicated it – once your test changes your code becomes a problem – It will crash all your scripts (Which is a good thing), but you will have to go over every duplication and change the code there – The solution is easy, Create methods – treat your automation like you treat a software!
2. Write clean code! As I mentioned in the previous topic – treat your automation code as you would a software! Think of the other people reading your test and trying to understand it, write clear variables names, use long method name that explains exactly what they do, use short methods that do one and ONLY one thing – for more information in this matter read my post: “Clean code in automation, Is it really necessary?”
3. Do not test more than one thing in your test method! – This subject might be tricky, I am not saying run the entire flow twice and do different asserts, if your test validates two things then, by all means, perform two asserts, but DON’T perform different flows and different scenarios in one test, this is a recipe for trouble – If your first assert fails your entire test will not run, and that’s a shame don’t you think? would a QA stop after that failure? probably not, a QA would have opened a critical bug but would have continued to find all the other bugs that are hiding afterward.
4. Give your tests good and clear name! I especially love this format for test method: WhatSectionInTheSystemAreWeTestin_WhatIsTheTest_WhatIsTheExpectedResult – This format tells the reader of the report what section was tested first, what was the test and what was the expected result – Don’t be shy! write long test methods name (Always think about the person that will read the error when you leave).
5. Short and to the point! UI automation should not test long scenarios because of the limitations it comes with (speed especially) for that we can perform integration tests… UI automation should perform short and simple tasks without complexed scenarios, our motivation is to perform many small tests that lead to a big step – so we will always know where exactly the crash occurs.
6. Write proper Error message! As I already written here before – Think of the person who is reading your report \ crash message. He or she will be wondering “What happened? why? what was tested?”. A good test method name gets them right to the spot, but it doesn’t tell them what exactly happened. I love this format of error messages: “Test XXX_XXX_XXX ran, Expected Y, but received Z”

• And a bonus tip for the champion automation engineer! When an error occurs take a snapshot of the browser, it feels so good when you are reading an error and you can actually see at the last thing on the browser (How do I take a snapshot in selenium browser? See examples here for C#, Java, Ruby and python.)

Keep automating,

Raz Shuty.