Selenium Best Practices

To become the best coder on the Earh, you should know the best practices. There is not a silver bullet and people love to argue about the best practices. We have created this section to find all possible arguments for each best practice and to find all pros and cons, so you can find them easily whenever you need them.

Do you know any best practices we are missing? Please, put them to the comments, so we can add them to the database and start discussing them with you and the rest of the world.

• Show All Categories

• Setup detailed automation tests reporting

• All tests should be independent

• Make tests simpler instead of adding comments

• Take screenshots for failure investigation

• Use soft assertions if you need to make list of related checks on the same page

• Name your tests wisely

• Make your test automation framework portable

• Separate your tests from your test automation framework

• Do not run ALL tests across ALL target browsers

• Do not rely ONLY on UI test automation

• Use relative URLs

• Don't rely on specific driver implementation

• Do not use Magic values

• Avoid Thread.Sleep and use Wait instead

• Use PageObjects Pattern

• Become a Best practice hero.
  Help us to grow the catalogue of best practices.
  Submit a best practice

Recently added best practices

• Keep _Layout.cshtml as clean as possible
• Always check what T-SQL is generated by Entity Framework and that filters are applied correctly
• Make Startup class as readable as possible
• Too many projects are bad
• Follow repository structure that Microsoft is using
• Review all code
• Have code standards
• Setup detailed automation tests reporting
• All tests should be independent
• Make tests simpler instead of adding comments
• Take screenshots for failure investigation
• Use soft assertions if you need to make list of related checks on the same page
• Name your tests wisely
• Make your test automation framework portable
• Separate your tests from your test automation framework
• Do not run ALL tests across ALL target browsers
• Do not rely ONLY on UI test automation
• Use relative URLs
• Review fewer than 400 lines of code at a time
• Do not rush. Do not exceed 400 lines of code per hour