Testers can write good code too Corina Pip https://iamalittletester.wordpress.com/
Twitter: Blog: https://iamalittletester.wordpress.com/ Travel blog: https://travelwithcori.wordpress.com/ Photos: https://www.flickr.com/photos/capreoara GitHub: https://github.com/iamalittletester/learning-project
testers LOOOVE to write A LOT of code
WHAT WE WANT FROM OUR TEST CODE To not be just a sequence of assertions To follow coding standards To be easy to read
WHAT WE WANT FROM OUR TEST CODE To be easy to maintain To be beautiful Repeatable results
FIRST STEP OF WRITING CODE ANALYSIS Make sure requirements are clear Spend time identifying best solution Write, draw, visualize
PRINCIPLE 0: THE LAZY PRINCIPLE Write as little code as possible Write efficient code Don t reinvent the wheel Use existing libraries
CODE REVIEWS QA should be included in all code reviews QA should ask for QA and Dev to perform test code reviews Should be included in DoD
REFACTORING Refactoring IS allowed When you have a more optimal solution
NO WORKAROUND CODE If the environment is to blame for test failures Rather, have the environment fixed
SEPARATE PROD / DEV TESTS Ideally create separate code projects for production tests and dev tests No more: oops did I just run that in production? Production = lighter tests; possibly lighter configuration Dev = everything Better dependency management
JAVA
USE PROPER NAMING, FOR EVERYTHING Classes; methods; variables; constants; packages; modules Give them a relevant name Makes code easier to read Makes it easier to find stuff TestUtils vs DbDataUtils; avariable vs randomemailvalue
REUSE CODE, DON T COPY/PASTE IT Results in fewer lines of code Single point of change Easier maintenance Available to many tests Don t create a new method for one line of code
REUSE CODE, DON T COPY/PASTE IT Don t pass in too many parameters refactor Don t pass in constants make them local to methods Process parameters in method don t pass the whole processing as parameter If method is too long, maybe break it into several ones
MIND YOUR TRY/CATCHES Biggest cause of tests that should fail, but incorrectly don t! Source of invalid results: not properly configuring the try branch forgetting about the catch branch
MIND YOUR TRY/CATCHES use cases 1. Test should only pass if the exception is not thrown - equivalent to codetoberunhere; - only useful if you want to throw specific exception
MIND YOUR TRY/CATCHES use cases 2. Test should only pass if the exception is thrown
MIND YOUR TRY/CATCHES use cases 3. Test should pass no matter if the exception is thrown or not
OPTIMIZE YOUR IMPORTS Don t import * except when really needed Import static when needed Assert.assertEquals(..,..) assertequals(..,..) import static org.testng.assert.assertequals; Don t leave unused imports
VARIABLE SCOPES Define variables inside methods/blocks where they are used Define inline variables if you will use them just once
SIMPLIFY YOUR IFS variable = (conditiontobetrue)? valuewhentrue : valuewhenfalse if (somethingthatevaluatesasboolean is true) {return true;} else {return false;} REPLACE WITH: return somethingthatevaluatesasboolean;
PROPER CONSOLE OUTPUT Print test data to your console where needed Helps understand the state in which the tests are Helps get a step by step idea of how tests run Helps reproduce issue when you output the data used by the tests When no visibility of tests running (e.g. CI)
SEPARATION OF CONCERNS PRINCIPLE
SELENIUM
DON T SLEEP. WAIT FOR IT When you know your system under test is sluggish - wait before/for all the actions page load button to be clickable label to have certain text CSS attribute to have some value
WebDriverWait wait = new WebDriverWait(driver, TIMEOUT); ExpectedCondition thecondition = new ExpectedCondition<Boolean>() { public Boolean apply(webdriver arg0) { try { condition; return true; } catch (SomeException e ) { return false; } catch (AnotherException f) { return false; }}}; wait.until(thecondition);
DON T SLEEP. WAIT FOR IT Better to wait than fail Don t sleep: hard wait; will wait for exactly N seconds Do wait: flexibility; will wait UP to N seconds You even can replace asserts with waits
DON T CHECK ISDISPLAYED THEN INTERACT WebElements are initialized lazily element.isdisplayed(); element.click(); REPLACE with: element.click();
DON T HARDCODE BROWSER IN TESTS Should switch easily from one browser to the other Avoids any one browser/driver not working Tests should be browser unaware Use getter to retrieve WebElements (when different selectors on mobile vs desktop)
USE LISTS FOR SIMILAR ITEMS <ul> <li>coffee</li> <li>tea</li> <li>milk</li> </ul> webelement1 webelement2 webelement3 List<WebElement> list.get(0)
TESTNG
DON T DO ALL TEST DATA IN @BEFORECLASS Do not create ALL test data in @BeforeClass All tests depend on the full generation of the test data Running a single test needs to wait for ALL test data generation to be done If test data fails to generate in @BeforeClass, an exception is thrown and no test will run Running from testing.xml takes much longer
DON T DO ALL TEST DATA IN @BEFORECLASS Move test data generation into methods where possible Keep only common test data generation in @BeforeClass
SOME TOOLS
Maven: Checkstyle plugin (DEMO) Goal: fail the Maven build when poor code is found 2 step setup: Import Maven plugin into your project
Maven: Checkstyle plugin (DEMO) Create checkstyle.xml file contains a list of checks on the code Maven, Google and Sun checkstyle files Extract from a checkstyle file: Failure example: For reference please go to: https://iamalittletester.wordpress.com/2017/08/22/us ing-maven-checkstyle-in-your-project-to-help-adhereto-coding-standards/
IDE tools IntelliJ: Inspect code (DEMO) Refer to https://iamalittletester.wordpress.com/2015/07/12/improving-your-code-by-usingintellijs-inspections-feature/
IDE tools IntelliJ: Inspect code (DEMO) Refer to https://iamalittletester.wordpress.com/2015/07/12/improving-your-code-by-usingintellijs-inspections-feature/
KEEP UP WITH YOUR FRAMEWORK Constantly take a look at the new features released Read the changelogs Take a look at the features it offers, apart from the most commonly used by you
CONSTANT LEARNING Learn the programming languages / frameworks before writing code Learn how to improve the code you wrote
FIND GOOD SOURCES OF INFORMATION Start with the official documentation Developers Trust them Don t trust them (they change their mind a lot) Google, StackOverflow, etc: check the code properly before using it Twitter, blogs, books, conferences, workshops
THANK YOU! Twitter: Blog: https://iamalittletester.wordpress.com/ Travel blog: https://travelwithcori.wordpress.com/ Photos: https://www.flickr.com/photos/capreoara GitHub: https://github.com/iamalittletester/learning-project