Add guidance for testing conventions in each language

[titusfortner]

Reason for PR

Each language has its own tribal knowledge right now for how it works, from annotations to helper methods to common locations for things. This is intended to document those things to make it easier to work in each language.

💥 What does this PR do?

Removes language specific testing details from primary README and moves everything to separate TESTING.md files

💡 Additional Considerations

This is in draft because they were auto-generated as a place to start. I updated some of them more than others, but they can all use a lot of work. Please assist, thanks.

[Delta456]

Hyperlinking to each binding readme would also be beneficial.

[titusfortner]

Yes, this is a good idea. I was going to do that, but our READMEs aren't consistent right now with what they do and don't contain, and I was thinking it might make sense to update them to mostly point to our website docs, and right now the coding agents we're targeting can't access the internet.

[titusfortner]

I added an issue to track this - #16740

[shs96c]

Nope! This will (at best) create a Chrome instance instead of the browser being used for the tests. The only reason why the browser is closed after tests is because the entire process tree is killed.

The correct way to start a new browser instance is via something like:

RemoteWebDriver.builder().oneOf(Browser.detect()).build();

[titusfortner]

Thank you! This is exactly why we need this file. (this is much more helpful than the generic warning I made about being careful hard-coding creation of new drivers)

Also, if you name it localDriver, it is automatically checked in after hook: https://github.com/SeleniumHQ/selenium/blob/trunk/java/test/org/openqa/selenium/testing/JupiterTestBase.java#L90

[aguspe]

I think we should add a section on how to use environment variables especially for BiDi testing @titusfortner :

Environment Variables

Environment variables control test execution behavior and enable specific features.

BiDi Testing

To run tests with BiDi (Bidirectional) protocol enabled:

# Enable BiDi for all tests
WD_REMOTE_BROWSER=chrome BIDI=true bazel test //rb/spec/integration/...

# Run BiDi-specific tests
bazel test //rb/spec/integration/selenium/webdriver/bidi/...

Available Variables

Variable	Purpose	Values	Example
BIDI	Enable BiDi protocol	true, false	BIDI=true
WD_REMOTE_BROWSER	Specify browser for remote tests	chrome, firefox, edge, safari	WD_REMOTE_BROWSER=firefox
HEADLESS	Run tests in headless mode	true, false	HEADLESS=true
DEBUG	Enable debug logging	true, false	DEBUG=true

Examples

# Run Chrome tests with BiDi enabled
BIDI=true bazel test //rb/spec/integration/... --test_tag_filters=chrome

# Run headless Firefox tests
HEADLESS=true bazel test //rb/spec/integration/... --test_tag_filters=firefox

# Run remote tests on Edge with BiDi
WD_REMOTE_BROWSER=edge BIDI=true bazel test //rb/spec/integration/... --test_tag_filters=remote

# Combine multiple variables
BIDI=true HEADLESS=true DEBUG=true bazel test //rb/spec/integration/selenium/webdriver/bidi/...

Testing Guard Behavior

Environment variables interact with test guards. For example:

# This test only runs when BiDi is enabled
it 'uses BiDi feature', only: {bidi: true} do
  # Test code
end

# This test is excluded when BiDi is enabled
it 'classic WebDriver only', exclusive: {bidi: false} do
  # Test code
end

Run with BIDI=true to see these guards in action.

[titusfortner]

Please add away, you should be able to commit to this PR directly. Everything here - https://github.com/SeleniumHQ/selenium/blob/trunk/README.md#ruby-1 should probably be included.
Thanks!

[RenderMichael]

A few lines about running tests in the IDE.

Suggested change

	### IDE Support
	The test infrastructure supports Visual Studio's and Rider's IDE, which can be more convenient in the inner loop when developing features and writing tests. Simply open the solution after building with `bazel` and the IDE should work like normal.
	Note that any bugs involving a discrepancy between the `.csproj` and `BUILD.bazel` files would manifest in running the tests through the IDE rather than with `bazel test`; any changes that affect either build systems should be tested with `bazel test` to ensure proper functionality.