I'm wondering what some other options are for accessing the test automation framework dependencies from my test classes.

Right now I have a layered architecture:

  1. Framework layer (contains all shared code for accessing deployed services)
  2. Harness layer (builds the classes and dependencies within the framework. Ie handles DI)
  3. Test layer (controls the flow of the tests via the objects created in the harness)

I've got a test base class in the harness layer that has access to the various API, database, and UI classes needed to run our tests. So using inheritance to provide access to these dependencies.

A sample test class would look like:

public class MyTestClass : TestBase
    public void sample_test()
        APIs.MyAPI.GetSampleEndpoint(); // APIs is an inherited field in test base

I feel inheritance is the best way to go about the issue of dependencies within a test class. The downside is managing the wrapping class that the "APIs" field is attached to.

Are there better options to go about managing a large list of dependencies in a clean way?


Are there better options to go about managing a large list of dependencies in a clean way?

Clean code is highly related to limiting access to dependencies - because depending on many things makes code more fragile to change.

If we take the S and the O of SOLID, we may come to conclusion is to create more abstract test class, for specialised dependencies.

You can have a class for API x and another for API y (more clearly, you name them after the functionality you are testing). And the test will derive from each specialised class, having access to only a handful (ideally one) dependencies. This would ensure that changes on other APIs wouldn't affect the target API.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.