Selenium · Browser automation foundations
How do you set up a maintainable Selenium project?
Short answer
Use a build tool with pinned Selenium, test framework and reporting dependencies, let Selenium Manager resolve drivers, and keep tests, page objects, configuration and utilities in separate packages.
A clean layout makes the suite easier to grow. I keep tests under src/test/java, page objects in a pages package, configuration and driver creation in support, and test data in resources. Versions are pinned in one place so local and CI runs use the same stack.
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>4.25.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>7.10.2</version>
<scope>test</scope>
</dependency>- Tests contain intent and assertions; page objects contain locators and interactions
- A driver factory reads browser, headless and remote settings from configuration
- Selenium Manager resolves drivers by default, so avoid committing driver binaries
- Use environment variables for credentials and grid URLs rather than hard-coded secrets
- Fail fast at startup if the browser or grid is unavailable
For remote runs, the same project should point at a Grid URL instead of a local browser. That means driver creation must be centralised; tests should never call new ChromeDriver directly.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Why should tests not instantiate drivers directly?
- 2How do you switch between local and remote execution?
- 3Where should test data live?
- 4What should be committed and what should be downloaded?
Say it in the interview
I pin Selenium and the test runner in the build file, let Selenium Manager handle drivers, and separate tests, page objects, configuration and data. Driver creation goes through one factory so switching from local Chrome to a Grid URL is a configuration change, not a code change. Credentials come from environment variables, and the suite fails fast if the target environment is unavailable.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Selenium mock interview and get scored feedback on depth, clarity and confidence.