As in my framework, I am creating the driver object by collecting the info from the test suite itself. We are passing the driver name through the testng suite and at runtime, we are collecting the info from the suite to create the driver object. Is there any other approach that can be used while dealing with driver object?
The ways of creating it really depends on the usage. But a general idea that indeed should be used is the Interface Segregation Principle:
“Clients should not be forced to depend upon interfaces that they do not use.”
It means that you should break down the interfaces that your tests deal with, to avoid having to deal with behavior it doesn't want.
For instance, your base interface for driver creation probably will have a
getDriver method. Some tests may require a
createChromeDriver, others may require
createFirefoxDriver method. They should interact with the specific interfaces.
Now, about the implementation itself, you can take advantage of Dependency Injection in order to allow your tests to inject some specific behavior.
A DriverManager object may require in its constructor a DriverCreator object. DriverCreator is an abstraction that may be fulfilled with any specific behavior (going to a config file, hard-coded data, calling a service, etc).
Usually, it is more important to implement any solution in a way that is easy to change than findind the best solution at first.
Avoid asking for the "best" solution here as everyone understands it in their own way. So asking for best is one of the best ways to get your question put on-hold.
As one of the alternative ways I can suggest to read web driver related settings from environment variables. This approach would let you
- decouple your test code and environment settings
- effectively run your tests from CI tools like Jenkins.