Hi, looking for input/best practices here. Currently, we open and close a browser for each test case. However, I can see benefit for keeping the same browser open for an entire suite. I could add the open and close browser methods to the setup/tear down code in each suite. My main concern is that if somehow the browser closed during the course of a suite, the following tests would fail inherently due to a missing browser. Just looking to see what others do.
Thanks,
Patrick
Same question here 
IMHO, Instead of to have the method call during the setup/tear down suite, Why not you have the checking if the browser exist @ listener? If not Exist, call the method to launch the browser again.
as MaKatalon suggested … and make it better, if the browser is not opened, as intended from the @before, it means something went wrong … crash or other voodoo. so abort the running test (enclose the test case code in an if … else or try catch) and raise a warning, error or whatever may be relevant
unfortunately we don’t have a ‘skip test’ method yet (fingers crossed one day we will) but you can use some logging tehnique …
We decided to open/close the browser in the teardown/startup code for each suite. It just saved waaaaay too much time to not do that. To solve the upstream test failure, we decided to take a similar approach as discussed above. We have a “login” custom method, which, as the name implies, logs a user into our application. Within that keyword/method, we added a few if statements to check the URL of the browser and navigate to the appropriate starting place, if if the URL isn’t what we want.
A side note, it seemed opening and closing the browser for each test also caused some extra and unnecessary flakieness. With the browser being opened and closed once per suite, this has cleared up some of the flakes. Seems webdrivers work better on cruise control, as opposed to stop and go.
Thanks for the input, all.