The next best practice that we're going to go over is using a Configuration object. Currently, before each of our test cases, we're setting a few options directly on our Eyes object such as the API key and our BatchInfo object that we saw in the previous section. While this works ok for our simple test suite, let's think about how this would look at scale. Let's imagine that we had many test cases spread out over multiple files. If we wanted to change any of the values that we're passing to the Eyes object, we would need to go through all of our test files and manually update them one by one. At scale, this is not a reasonable approach as it becomes difficult to maintain.
What we recommend as a solution to this problem is to create a Configuration object. Rather than needing a bunch of calls to eyes.set() methods, we can instead create one configuration instance, set all the values that we need and then make a single call to eyes.setConfiguration() within our tests. Then, if we needed to update our Configuration, we only need to update it one place, rather than multiple places across our framework.
Additionally, using Configuration objects allows us to create and maintain multiple configurations for various situations. Then, we can pass in the relevant Configuration object as needed. As an example, maybe we'd have one Configuration for desktop tests and another for mobile tests. In Summary, using a Configuration object allows our code to become much cleaner and easier to maintain. Let's head over to our code and add a configuration object to our framework.
Let's go over what I added in. Firstly, I created a configuration variable at the top of our class.
Then, I initialized this configuration object and applied our API key and batchInfo object to it in the beforeAll hook. These were previously being set directly on our Eyes object.
Finally, I replaced the calls to eyes.setBatch and eyes.setApiKey with a call to eyes.setConfiguration and passed in our newly created suiteConfig object to it. As our test framework continues to grow, we could move this configuration object to another class and then reference it as needed in all of our files. Rather than having to set our API key, batch and other configuration options in each test, we can set all those values once and then pass the Configuration object around. For now, what we have here fits our purposes of highlighting the Configuration object and how it can be a helpful tool for writing easily maintainable code.
In Summary, The Configuration object is considered a best practice as it allows us to set up the Configuration for our Eyes SDK once and then pass that object around as needed. This can allow us to clean up our code and make our framework more scalable as it grows. Additionally, it provides us with the flexibility to set up multiple configurations for multiple environments further boosting the maintainability of our code.