Selenium Test Automation: Practical Tips & Tricks - with Dave Haeffner (Part 1)

hi everybody can you hear me okay excellent anyone want to write an automated test for this microphone make sure you can hear me all right that's the only bad joke I'm gonna tell so don't worry about it okay so listen again I think it's worth starting with the beginning when I first started doing automated testing with selenium about 6 years ago I thought that it was this scary thing that I had to figure out I wanted to go from one side of a chasm to another and there was no bridge between the two that's how it felt when I looked at the selenium documentation there was no clear path and it's worth mentioning that after six years the selenium project documentation hasn't gotten any better so if you're just getting started now you probably think the same thing so what I think it's worth pointing out and what the point all this and what I learned is that it's not this big scary chasm you have to jump across working with automated testing within your organization is actually a lot more like a like a puzzle like a Rubik's Cube and how many people show hands have played with a Rubik's Cube or at least know what it is and but keep your hands up if you know how to solve a Rubik's Cube I got a couple okay cool so you can ask them if this is true or not but the cool thing about a Rubik's Cube is no matter its orientation you can apply the same patterns to it and solve it and I argue that the same thing can be done within any organization when it comes to automated testing you may think that your problems are unique but they're not it's just a puzzle you apply some patterns and practices and voila you're on your way to being successful with selenium so I always like to start with that story and this set of sentences this is the goal the reason we do all this we want to write business valuable tests that are reusable maintained scalable resilient across all of the browsers and then you want to package them up so that you're not the one running them that they're part of this ecosystem that you and your team use and the best way to do that I guess is to understand a little bit about Salani to make sure we're all on the same page and have a good working glossary of everything I'm going to talk about and then we'll kind of dig in more into the weeds as we progress so the first 45 minutes of this talk is really about kind of the end-to-end soup-to-nuts of what I think is an overarching approach to using slam successfully and then in the second half I'll cover some tips and tricks and more advanced topics and then if you stick around to the very end you get to see a mobile testing robot so just spoiler alert so selenium is what it is The Reader's Digest version selenium is a robot I'm a made of software sent from the future to help us test websites at least that's what the Creator Jason Huggins would tell you if you asked him over beers or coffee and that's basically it's something that drives a browser in an automated way and it mimics human action is good at mimicking human action but it is not good at being clever there are things that you can do with it if you really really wanted to like check the HTTP status codes of a page and resources on a page but it requires additional setup and it can lead to additional issues so any any time that you think hey I maybe I'm a my being clever and when I write tests if the answer is yes or maybe then maybe you need to stop and question whether or not using selenium for what it's good at and is this the right tool for the job so as long as you're mimicking human action you should be in good shape there's various flavors of selenium assuming and I'm hoping that you're all nodding your heads and you're like yep we already know this so but for the most part just for the uninitiated there's a record and playback tool selenium IDE I'm assuming if you've ever heard of selenium you've heard of this maybe you've used it don't use it that's the easiest answer I can give you there are of course exceptions to everything that I say here but the way I approach a lot of this stuff is I give you recommendations and when you have a clear understanding of why you want to do something different than what my recommendation is great then you are ready to do that thing but until then if you have no clear understanding just stick to these guidelines and you'll be fine so recording playback bad idea then when you have tests written in code you can run them locally on your machine or you can run them remotely on other machines and then that gets into this whole conversation of a scalable grid and is it your grid or somebody else's grid and so on and so forth selenium mostly has a bad rap for being slow brittle and hard to maintain but I'm gonna cover a lot of practices and patterns and tips about how to actually structure things so that you can address almost all of those issues granted there's always little nitpicky things that you have to deal with and there's never there's no such thing as a hundred percent test automation or 100 percent perfection when it comes to automation but you can get most of the way there so and before you really write tests there's a couple things I want to talk about mainly defining a test strategy and this isn't like this really abstract concept I actually distill it down into four questions and if you haven't asked these questions in your organization or if you don't know the answers to these questions in your organization then maybe we should ask these questions so the first one is how does your business make money and and if you don't deal directly in dollars and cents if you're more like a non-profit then how do you generate value for your user and then what features of your application are being used and since you're most likely not dealing with super secret corporate federal data you probably have access to usage data like Google Analytics to be able to understand what actually is being used in your application and then you can also determine from that usage data what browsers people are using and then this is a little harder but what things have broken before in your application now the easiest thing is when there's a release about to happen and you look and you see a developer sweating you can go ask him why are you so nervous about this release and they're likely nervous because there's something in the app that's broken before there's something that's keeping them up at night there could be also information and a defect tracker there's a litany of places that you can pull this information from and really what this what the answers to these questions give you is what to test and which browsers you should care about now that takes you from figuring out everything you should automate to maybe the important things and if you're already doing automation and you ask these questions and you have found things that aren't being covered by automation then maybe you should add those to your automation cycle how many people here already use selenium in their organization it's like 80 90 percent cool so I'm assuming you're all using Java how many people use Java I almost died okay any Ruby people out there okay so I have some code examples they were in Java in these slides so for the none Java people I apologize but hopefully gets mussed you going so some I bring up picking a programming language partly for people that are new to this but also for people that maybe already have a framework and then they're like you know what we're doing Java but Java scripts pretty cool maybe we should rewrite our framework so the general this happens more than once so a lot of people think that you just write your tests in the same language as the application that's just the default assumption people have when they go into automated testing and instead a better question to ask who's gonna own it now if you're the front-end developer and you want to do testing and you write your front-end in JavaScript and you say hey I like JavaScript let me write my tests in JavaScript I don't like Java there may be something to that but especially if you're gonna own it it gets you excited and you're gonna want to write tests writing test is a good thing there's also the conversation of do you build a framework or use an existing one I say an existing one because I keep a list of all of the open source lean frameworks that I come across in my journeys and there's at least one for every language fun fact I'm assuming you already know this you're going to want to build your own nobody ever says I'm gonna use an open-source framework I know because I wrote one and nobody uses it so it's on that list if anyone wants to do it in Ruby now there is and if and if there's anything that's missing if anyone any of you look at this and say hey my frameworks not up there and it's open source shoot me an email my contact info will be at the end okay so let's talk real quickly about selenium fundamentals as I mentioned it mimics human action and there's a few common actions that you're going to end up using over and over again and then selenium in order to work it uses locators and I'll cover what those are but basically the gist is locators tell selenium which element in a page to interact with which bits of HTML so common actions you're going to run into just to get started you're going to want to get a page there's other ways within selenium to do this but gets the easiest most common you get a URL and then you're going to find an element on a page and once you find an element you can do some actions to it you can click on it and if it's a form you can also submit the form and then when you want to type into an input field you send keys and then you can also see if something is displayed that's worth pointing out that for all you front-end keeps out there click and seeing if something is displayed like there's a lot going on under the hood with selenium it's not just like a jQuery click event it's like making sure the element is actually clickable and when something is displayed it's actually determining if there is an overlay on the page is it actually not hidden it's doing a whole bunch of stuff for you so when it is when it says yep this displayed it's just the rough equivalent pretty close to a human actually looking at it and saying yeah yeah I can actually see it and I can actually it's actually enabled I could click it if I wanted to all that stuff so in terms of different ways that you tell selenium what you want to interact with when you find an element you specify a locator and there's all these different strategies and when it comes to locators there's some really simple advice I like to give and it's good locators are unique descriptive and unlikely to change so when you put that in mind that rules a few of these out now if you take out link text and partial link text and tag name you can use these but just keep in mind that these could potentially be something that's more likely to change instead try and start with IDs and classes these are going to be the fastest way for selenium to actually interact with an element on the page and ideally they'll be hopefully named they'd have some sort of semantic markup to them and then if you need to get to those harder to reach places if you need to actually traverse through the page then use CSS selectors or XPath but do so with care because you can write really poorly performing CSS selectors and XPath locators that are also extremely brittle and in the past and even still today there is actually a lot of contention in the selenium community about CSS or XPath is like this kind of internal battle and it used to be that XPath was extremely slow in selenium and and that's changed the benchmark data people were referencing is several years old so and even mine is old but I went a year ago I went through when I did benchmark tests for everything and it's actually negligible like CSS is a little bit faster so if you want to see the benchmarks and all the data then check out that first link and if you want to see some CSS and XPath equivalents then you could check out that link and the recommendation on CSS versus XPath I typically go with CSS selectors and I'm assuming all of you do those of you that actually write selenium tests now and then for those harder to reach things where you want to go and traverse backwards up the page use XPath now in terms of finding quality locators hopefully most of this is rudimentary for you guys but there's the obvious right-click on an element in your browser and inspect the page if you're using a modern browser hopefully you are not links or ie6 or something like that then you can inspect the page and see what what the market is and verifying your selection now like in a in a Java console with jQuery all you front-end guys will know this is really easy to do but for those that you don't know if you're just started with starting with automated testing what most people do that aren't developers who do automated testing they look at the page they find the locator they want and then they go and they write their test and then they run their tests wait for the browser to load and look and see if it did what they thought it was supposed to do and then when it doesn't they go oh shucks and then they go back to the page in the browser and then they rien Specht and they look again and they go ah I got another locator to try I think I've hacked to their test and it's extremely slow feedback instead you can verify your selection in the browser and the there's plugins galore for this but there's a end up using Firefox with Firebug there's fire path and fire finder plugins that give you the ability to drop a locator into an input field hit enter and it actually highlights it outlines it on the screen for you it saves saves you a ton of time and so hopefully maybe there's a couple year they have like oh wow that will save me time because it'll save you like hours a year and a lot of frustration so I have a write-up on how to use fire finder steps through like an actual issue I had one when trying to do the benchmarks with CSS and XPath so a good use case there and then there's this locator game if you're new to locators specifically CSS selectors this game is really interesting it's an open source game it's just these little dancing plates and then you have to type locators and then it like so you can actually hit targets on the plate it's really interesting so potentially a fun way to to begin on that and then having a conversation a lot of times when you're if you're not the front-end developer and you're just a tester on the team writing tests it's very much a arms-length kind of experience where you're trying to write tests for this thing you didn't build so you're trying to understand the markup find elements that you want to click on and then figure out a way to write your tests to do that and there's plenty of times where the markup on the page is built for automation it ends up being a very challenging exercise and then what you end up with you may end up with working test code but it may be brittle and if you just actually had a conversation with the Devas and said hey here's what I'm trying to do they may go oh try this or whoa let me add a unique locator to the page and then poof your test writing is easy so and then they get a better understanding of what you're trying to do all the time and they may actually change how they build and construct the apps your testing so communication collaboration all that good stuff here's a quick video of fire finder in case you're interested once you open Firebug there's a fire finder tab that gets added you can inspect and hey look there's this ID login let me see what that looks like you type it out hit enter tada you get dashed outline of the element on the page and we could do the same thing for the username field and the password field to make sure we got that and then we realize well we do the button that's cool all right so we could take those locators and write our first test but before we do it's worth talking about good test Anatomy just to make sure we're all on the same page because a good test has like a handful a few things that really should exist in all tests your test should be written to use some kind of framework that already exists a test framework whether it's a behavior driven development framework or an X unit framework of some sort because it gives you the structure you already need and gives you the ability to run your tests it gives you all the minimum reporting that you need in terms of like how many tests ran how many failed etc etc it just gives you a lot of functionality that you don't have to build and each test ideally will test one thing it will be atomic it will have a single assertion and each test should be able to be run independently there should be no dependencies between tests one test shouldn't run to set up another test and this is a big one because if you don't do this you won't be able to run your tests in parallel and then you want to make sure that anyone can understand what the test is doing not just another teammate but potentially you six months from now when you come back to the code and you look at it again and this goes this falls back into the are we being clever category ideally testing is really just a boring activity so you should write boring test code that is easy to understand that doesn't do anything clever and then you want to make sure that you group similar tests together so if you actually want to create some sort of custom test suite that does like I want to check login and then I want to check this purchase activity and this other stuff over here you don't write a test file that has all those things each of those things live in their own files in the proper folders that denote that functionality and then you can use metadata to actually tag each label each of those things and in Java with Jane it's categories and then Ruby with our spec it's it's tags but basically at runtime you can specify that label and it will dynamically create a test pack for you that consumes all those tests that you want to run so that way you don't have to each thing has its own place and then at runtime you tell it what you want to run as opposed to trying to create it statically so taking those locators here's what selenium would do to use them it would first visit the login form with the get action and then it would find the login form as user name field and then input text or send keys it would do the same thing for the password and then it would submit you can click the submit button after you find it or you could find the form and submit the form so I have this website called the internet so I write and maintain the Internet only because I could tell that joke but this is the example we're gonna write the test against which we saw when I verify the locators so here's what the selenium commands would look like in Java of course I've removed the setup and teardown but you know you have a driver object which is the instance of selenium and you would get a URL and then we'd find an input find input submit and what that looks like in a simple j-unit test is this granted this is the very first test so we have nothing abstracted we just have our setup which runs before the test and we have the teardown which runs after and then we have our test method and we're just loading an instance of Firefox now when we run this it will of course pass because there's no assertion that's the other big advantage we get by having a test framework assertions so we can assert we can determine if the behavior of the page is what we expect and we can get that information with selenium so to find assertions we would for this example log in inspect the page after logging in find the locator for it verify we have what did we expect and then add it to the test so for this we'll just log in with the good old Tom Smith and his super secret password and then afterwards inspect the page we'll start with the logout button maybe there's something helpful there that's semantic but really is just a button it's no good locators it's garbage so then we inspect this flash message and we see that in the class there's actually something that says success something semantic that denotes the state of the page and so let's say all right let's grab the flash success message and then a CSS selector for it would be dot flash success because classes start with a dot and then we get it tada so if we put this in an assertion we would assert true have a failure message that would appear if the assertion failed and then we find using the CSS selector and then we use it after we find it we say is it displayed and selenium will look and say yep it's displayed it will return a boolean and then we'll assert if that boolean is true and that's pretty much it if we run this it would work and if there was something wrong with it on the page we would know and one helpful tip when writing assertions or even writing anything with selenium for that matter it's worth trying to force your test to fail to make sure that it's doing what you think it's doing and for this example like fudging the locator like over here we'll do that there's plenty of times I've written a test and I think I know it's going to do exactly what I think and then I fudged the locator and then it still passes it doesn't fail that I'm like what is happening I don't know what's happening anymore so I leave this comment really as a reminder to myself too to give that mention to you because it saved me a lot of headache by doing that fun fact if you were to assert false so if we wanted to go the opposite direction here and say maybe the flash error message that would appear if we gave a bogus login info would appear so we could assert that it didn't appear on the page so we would check for the negative condition of something so say hey selenium did something not appear on the page and when we look for some when we look for something that's not on the page selenium won't you know is display we return true if it's there but if it's not there it won't return false it will return an exception so that's your runner-up prize so what you get is a no such element exception and this is just one of those things that we have to account for in our test code and there's two common exceptions you're gonna run into no such element and style element reference error for the most part you can very easily just you know catch these exceptions and move on and not really worry about it and if you want to see a full list of the exceptions perhaps some light bedtime reading feel free to check out that link and in order to just catch on this is display and return faults instead of an exception we can just do this we can try the action and return faults if it gets thrown so now we have our first test let's go ahead and make it reusable and maintainable page objects who here uses page objects who here knows what page objects are that's not as funny fewer people then use them cool all right guys are we heard all right page objects okay so if we keep going on the way we're going right now we will have all these tests written directly against our application and then they'll fail if the application changes and we have to go and update all of our tests and then we'll have a sad face instead what we can do is separate the concern we can create a page object a class that represents features in our application and put our locators there and write our tests against that and that way we only have to update just the page object to make all of our tests pass and then we smile now we're happy again so do that it's probably one of the most fundamental things that every test Automator does it's the most common pattern that's used because it's the most useful one so let's look at a page object for our login example at the top of it we have some field variables where we specify the static locators and then we use them throughout the rest of the class down here we have our the core behavior of the page logging in with a username and a password and then we just grab the slutting commands pull them out of our test put them here and now we have a dynamic method where we can specify any username and password combination we want and then to check if the success message is present or even the failure message we have separate methods that will return billions for us and in the constructor I'm handling how to get to the page and then checking to make sure that we're in the right place normally you really don't want to have any assertions in your page objects but this is one potential use case to break that role you could also instead raise an exception there's several different ways to handle it and during the break between sessions if we want to if you have strong opinions about this we can wrap about it but what this does is it gives us the ability to pull things out of our test our selenium commands and our locators and then instead have something really simple we create an instance of this login page object pass in the selenium and now we can login with the username and password and then assert that the success message was present our tests immediately become readable and immediately become maintainable and then it's easy to add another test so there's some additional page object helpers what I showed you is just a very simple plain old java class but there's things like HTML elements which is from a company Yandex the they're based out of russia they've done some tremendous open-source libraries HTML elements is one of them it's so helpful wrapper around page objects that makes it a lot easier there's also one built into selenium called the page factory these are both worth checking out or you can just stick with just writing your own classes and there's one more that a lot of companies actually either have some variation of or just don't do it I call it a base page object it's essentially an additional facade layer some companies call it a selenium wrapper some might just call a base util class but whatever it whatever you call it what it is is this right now if we keep going the same path of how we're writing page objects we would be writing selenium commands directly in all of our page objects and then if there was an update to selenium that had breaking API changes we'd have to go and update all of our page objects plus we don't have really a central place to handle how we want to do exception handling unless we wanted to go through all of our page objects and put it in different places so we don't really have a centralized place to control all that so what we can do is create another abstraction layer so we can move all of our base commands into this base page and then those would reference the selenium commands directly so what this gets us is global reuse and it insulates us from selenium API changes and this additional readability more so than what we had before in our tests and if you're interested in seeing why this matters and how it was done at scale this link takes you to a write up recap of the closing keynote from a selenium conference in Boston a couple of years ago where Jason Libya from Google talked about migrating millions of tests from selenium 1 to selenium 2 and how this pattern is what they worry what they use to effectively do that now granted going from selenium 2 to slam 3 should fingers crossed not be a rocky ride like it was from 1 to 2 but this is just another helpful abstraction that could save you some time down the road so what that looks like a very simple base page object is this I'm basically creating and taking the methods and creating my own I'm creating a domain-specific language where I have instead of get a visit and then instead of fine element I have find and then I've click and instead of send keys I have typed their submit and I handle the the try catch for the exceptions here so now it's just done in one place so now we have we're not repeating ourselves we have central location and we're starting to be in a position where we can extend functionality if we need to it's a little more robust so what that looks like in the page object for login is this now we just have instead of driver yet it's just visit the URL and then all the other methods that we just created so now our page objects become more readable so it all fits together as tests use the page objects page objects inherits from the base page object and then the base page objects ends up using selenium actions so now that we have all that let's talk about making test resilient probably the meat of this really what it takes to do selenium really successfully aside from all the table steak stuff that I've already covered it's has to do with weighting making sure that your tests are resilient with the way your website your web application behaves because how many people here use JavaScript only four okay great well then this will be easy for you know in a sense of how many people test applications that have javascript that's a better question all of you great ok so there's three ways to weight in your tests and I'll let you wager a guess which one you shouldn't do first thread sleep don't use a thread sleep and if you're curious why the easy answer is it's a bad idea you by adding thread sleeps you actually force your tests into always waiting that amount of time there's no dynamic flexibility to how long your tests take to run with in selenium there's two weight functions there's an implicit weight and then there's and then there's explicit weights so an implicit weight when you create an instance of selenium you can just say wait for this amount of time so every action that selenium does if it tries something and it's not able to complete it it will wait that default amount of time that you just specified but there's caveat it doesn't cover all conditions for all actions and depending on how your applications built there are plenty of use cases where things fall through the cracks in your test end up being brittle instead you can use an explicit weight which is a little bit different and I'll explain that in the next slide but what's important to note is that you should never mix an implicit weight with explicit weights and that's because it will cause transient failures in your tests because there are differing implementations of implemented implicit weight across all different browser drivers and in selenium remote so really you just shouldn't use an implicit weight and instead we'll see use explicit weights not explain what those are and if you're curious about more more detail about the specifics I have this write-up would actually I step through with code examples what I mean and show some ways that you could abuse implicit explicit weights if you really wanted to but next Blissett wait let's talk about that so with explicit weights for an action that you want to add a weight to so say you have you click a button and you want to wait a certain amount of time for something to happen you would wrap it in an explicit weight and so you specify an amount of time in the action you want to do and selenium will try that action repeatedly until either the action can be complete it and if it is say it was you wait you said 10 seconds to wait and it was able to complete it in two seconds it'll move on it'll just go to the next action after that if it's not able to do it it's gonna keep trying for that amount of time you specified and then once it hits that that top-level time is going to throw a timeout exception and so what that looks like here is on the internet there's a simple dynamic loading example where when you click start loading bar appears and then after a few seconds it disappears and some text appears on the screen so you can grab this locator we can verify that this finished text is what we think and so now we can write a test but if we actually just wrote a test saying open this page click this button and then see if something's displayed it would fail because it doesn't selenium doesn't know to wait it's dumb it just won't wait so what that would look like for the weight function there's a couple different ways to do it but the easiest one is to you use the one that's built into selenium there's a webdriver weight function and I've created this private function it's just called wait for it accepts an expected condition and the expected condition that I'm passing in in this example when I use this method is the visibility of the element located so basically we're effectively doing is displayed and we can also specify timeout now since so the what the best way to do that I found to do this was have a conditional that checks to see if null is passed if it is use a default timeout you specify here so for this example the default timeout is five seconds and then it'll wait until all that happens and so up here what we can do is say wait for expect a condition of the visibility of the element and in here I'm making it so it's optional to pass an explicit wait time so when we call wait for is displayed in our page object we can just specify the locator if we specify no timeout five seconds will be how long it waits or we can override it so we're effectively getting the implicit wait functionality for free with this implementation but we're also not going to run into issues later on so what that looks like when we implement it inside of a page object that would exercise the page I showed you it's this you have you visit the page and you click start and then you wait for is displayed and you pass in the locator and then we override the default timeout say 10 seconds so when you run this test once we wire this up to a test it'll run and it'll actually wait so hmm there's some additional browser timing considerations to think about since synchronization is the biggest challenge I think in doing successful test automation aside from all the normal infrastructure challenges most people what they'll do is they'll write their tests in the browser that they're comfortable with and usually within selenium the easiest browser to get access to is Firefox because it comes built into selenium and most people already use Firefox so they're good to go so you write your tests you say hey I got working tests awesome now I'm gonna run them in another browser so you set up another browser and you run your tests and then you start getting failures like wait they were working in this other browser what happened and there's a lot of reasons for it it could be it could be that your application you're testing is actually responding more slowly because of load but it's probably actually that the browser is executing in a different pace than what you wrote your tests against so say for example you write your tests in Firefox then you go and test an Internet Explorer 8 it's not necessarily an advised idea but say an older browser that's slower like IE and what you'll end up with is maybe IE runs a little slower and your tests need to be tweaked so the timing can actually wait a little bit longer and then you do that so then you have working tests in ie and Firefox and they say let's go to Chrome and then all of a sudden you have your test braking in Chrome for different reasons probably because chrome moves a little too fast and then you missed some weight conditions you need to add so other parts of your test and then basically what you end up with is these explicit weights kind of sprinkled around your test code a lot of people think that's like that's a smell but really that's the recommended approach by selenium committers as opposed to using an implicit weight but it's worth it because what you end up with then is tests that work in all these browsers but you can't really just write your tests once and have them running in all browsers it's not as easy as that it's an iterative process where you have to tweak it constantly and keep trying until it gets gets to a point where all your tests are green and all your browser's okay Fred Frese and how am I on time ok great step 7 prep for use so since everybody here already has a test harness that they built themselves or they're thinking about it let's just go ahead and talk about building a test harness with selenium so the first thing is a simple organizational structure the first thing any company ever deals with when a new software project happens aside from what stool we're gonna use since we already know it's selenium it's like where do things live what's the folder structure and then you want to make sure that you pull things out of your test so each test isn't responsible for setting up and tearing down selenium you want to put it in a central place so that we you can add more stuff to it so you can say oh not just Firefox I want Chrome and then I want to run it on a grid and so on and so forth and then you want to make sure that your tests you just write your tests and then at runtime you can configure which brow you want you want to be used and then also other things like a base URL and other kinds of sensible defaults and then the other important thing is when I test fails you want to know what happened you want as much information as possible you know with selenium that comes has the ability to take screenshots out of the browser your test your test framework that you're running on your unit testing framework should give you a lot of logging information but then you can also attach a logger and output a whole bunch of additional debugging info so really a lot of times what could happen is you run your tests if there's failures you're on your tests and then they pass that's not helpful you can't really trace down issues that way so what the best thing you can do is find as much debugging info as possible to look at your tests when they failed to figure out what actually was going on and then you want to be sure that you run things in parallel because it's great that you have all these robust tests now but what about not running them in series running them as many of them at once as possible and then you want a way to flexibly and easily run your tests into dynamic groups at runtime so folder structure that's boring let's go into this central setup and teardown would look something like this where you have some sort of ability to actually set up something before and something after and in our test before we were using before and after annotations but pulling them out into a central base class like this using before and after annotations would actually remove them from being useful in your tests because the order would be wrong so in this example I'm creating a base test and then I'm going to update my test to inherit that extend that and so in J unit there's actually an external resource test rule that gives you the ability to fire a before method before the before annotation so if that's not clever enough this is the only clever thing I'm doing just whatever I said about clever you can ignore for this right here so but this gives you the ability to have a centralized place to store your setup and teardown code and then extend it and if you're curious about Jana trolls who's that URL goes to the documentation and then some way to specify configs config variables so I mentioned runtime configurable the way that I've approached it in JUnit is to use - D flags so runtime properties and then have a way to catch those and put them into values that I can and I can pass around in a config object and then have sensible defaults so if I specify nothing my test will still run right they'll run in the most important browser I think at the time which according to this is Firefox 33 on Windows XP ok and then you would just implement the config interface and wherever you want it could be in your base test could be in a base page object but then you have access to the browser and all the other goodies like a base URL and so on and so forth and in terms are reporting and logging what I mean by that is machine readable things like jaina xml that can be consumed by your continuous integration server and then human readable things like screenshots fill your messages stack trace information so you could find that smoking gun and there's actually I mentioned the index guys earlier and they have this fantastic reporting tool called allure that it's actually language agnostic and they have bindings for pretty much every test framework that's out there for every language and anything that's not already there there they'll added if you the probably add a few sentimos support requests so at this link I have a write-up of how to do it using Ruby and r-spec but the the documentation is really good too so it's worth checking out because they make it very easy to get a very robust HTML report generator with screenshots and so if you don't already have that don't you don't necessarily need to build it someone else already has and then parallelization there's a few ways to handle it there's always writing your own code your test run or may already support it and then there's also certain continuous integration servers that handle it - like solano labs like TDD iam is one option but the way for Java and j-unit something like the maven surefire plug-in or the maven failsafe plug-in fantastic it's literally like a block of XML in your pom.xml file and you have parallel execution it's amazing and the pro tip here that I have is when running tests in parallel there will be transient failures that is just the name of the game especially if you have test dependencies and you don't know it and the best way to bubble those up is to run your tests in random order all the time and within j-unit there is a another library that handles that for you it just gives you the ability to add another run with parameter like a little annotation then you're on your on your tester than running in random order it's fantastic it also gives you the added benefit of exercising your application in a random order which could also identify and bubble up bugs in the app and um I'm getting close to the end so I think okay everyone stop here cool all right want to take a break cool all right let's take a break

Channel: Applitools: Visual AI Powered Test Automation

Views: 44,124

Rating: 4.8978391 out of 5

Keywords: Test Automation (Software Genre), Software (Industry), Selenium (Software), Quality Assurance (Industry), Software Testing (Industry), Dave Haeffner, UI Testing, Visual AI, Automated UI Testing, Functional UI Testing, Visual Testing, Application Visual Management

Id: cIevkkD_LB4

Length: 43min 10sec (2590 seconds)

Published: Tue May 05 2015