Note bellow article is dedicated for C#.
When I am writing Selenium Test –
I like to let them run until they fail and then leave the browser opened on the place where their failed. IT helps especially when the problem is poorly selected locator (Which is a common issue when writing UI tests).

The Easiest Way

If you are just writing completely from scratch it is easy.
Until you perform Quit() on your driver the browser will stay open.

But if you have already some semblance of the framework with the abstract test base that opens and closes driver. you have to do something.
the simplest way is to comment it out.

        [TestMethod]
        public void Example_Test()
        {

            driver = new ChromeDriver();
            driver.Navigate().GoToUrl("xxx");
            var loginPage = new LoginPage(driver);
            loginPage
                .InsertLogin(login)
                .InsertPassword(password)
                .ClickLoginButton();


            //driver commented out for debug
            //driver.Quit();

        }

Well, this has its cons. You may forget to uncomment it before you commit/push your changes. Which may make problems for your CI or other users. You don’t even want to know how many times I have seen that – including doing it my self.

Yes in code review this thing will be usually caught, but it will cost you time.

You can use app.config to leave the browser opened.

Another option is to create some methods that check config file have this setting in config – and this is one of the best ways to approach it.
In your app setting, you can put key for it.

App.Config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <!-- other setting-->
    <add key="CloseBrower" value="false"/>
  </appSettings>
</configuration>

example of using the key

        public static bool GetCloseBrowserSetting()
        {
            return Convert.ToBoolean(ConfigurationManager.AppSettings["CloseBrower"]);
        }

    [TestCleanup]
    public void Cleanup_With_Config()
    {
        if(GetCloseBrowserSetting())
        {
            driver.Quit();
        }
    }

In theory, you can mark the file to be ignored when doing commits. Unfortunately, from my experience, it is not a good idea. Configs change more often than test base class. So making config ignored at commit can lead to other problems.

There is one more thing we can use.

Build Configuration and Preprocessor Directives

You know these options?
Debug and Release? Those are Build configuration with info on how to build the application. For example, Debug has all info necessary to run debug. Release, on the other hand, don’t have it thanks to it is faster.

We will use it for our purpose by creating a 3rd setting called „TestDevelopment” – which will leave browser on.

First, we have to create that configuration
Go to build -> configuration manager. (or ctrl+q and type configuration). Select new from drop down.

Name it whatever name works for you- I went with TestDevelopment.
You can select to copy setting from Debug.

Now you need to right click at your project with tests (Project not Solution) select properties.

Go to the build tab. Select TestDevelopment in drop down. Next, in conditional compilation symbols enter TESTDEVELOPMENT – or whatever name you chose. The naming convention dictates the whole name has to be capital letters.

We have just created a Symbol used by preprocesor directives.

Now we have to use it in code.

        [TestCleanup]
        public void Cleanup_With_ Preprocesor()
        {

#if TESTDEVELOPMENT
            //if you want you can put some logger or warning here    
#else
            driver.Quit();
#endif
        }

Now you can select from configuration drop down TestDevelopment and run your tests.

Voilà! – Browser wasn’t closed!

Now when you commit your changes, the info which configuration you are running locally won’t be committed.

Summary

There is many more ways to leave the browser open.

App.config and commenting out are most popular. And as far as I know using preprocessor isn’t as popular. Each of the options has their pros and cons. Comment is the fastest and definitely most useful when you just start writing automation. But as time goes by you should move to either pre processor or app.config.

That’s All!

At some other point, we will talk how to join this approach with configs. It was refreshing to do technical post after such a long pause.
If you like this you should check my flowers series. Or see 300 for my main content.

*Edit* Fixed few mistakes, Huge thank you to Magda for pointing them out.