2

Scenario: I have a repository that contains a component which is reused across multiple different projects. The component in question is a image viewer component.

3 Products will use this image viewer for displaying image(s) in their respective web applications. I am tasked to create some end2end / gui functional automated tests for the component itself and have been asked to try and make sure we don't have to write automated tests to cover it in each product which implements it.

my initial thoughts are:

  • Write some automated tests in the component repository, which spins up an environment running the component standalone and executes the tests.
  • A large degree of the task is somewhat flawed, each product will have different tests regarding the image viewer, the steps taken to launch it with an image will be vastly different, so there will be repetitive code and tests there per product
  • Deploying the component stand alone is not really an end2end or integration test because it is not consumed or used by anything under test at that point, we would still need to test it in each individual product once it has been implemented.

How can I best approach this problem to generate reusable tests, what should I advise or discuss with my manager regarding the task at hand?

The stack used would be, java/c# selenium based tests, the component is written in typescript.

1

Use Inheritance.

In the OOP , we use inheritance to define an base class(component page object class here) and define all the common behavior as methods.

Then we inherit specific derived classes inherited from base class overriding behavior (methods) specific to that class.

By overriding base class methods , we achieve reusability as the common code is not repeated but overridden to the extent it is changed in an specific instance.

Typescript Classes and Inheritance.

  • 1
    I know that this is normally the accepted answer, but I have already heard otherwise and from my own experience using inheritance too much (and this case looks like more than basic usage) leads to maintenance hell. You end up with multiple copies of the same and have to dig deep to understand what is implemented where. Yes, careful documentation and consistent implementation can help, but please be careful and don't over use that. – Rsf Feb 16 '18 at 12:36
  • Just google "inheritance is evil", obviously like many other things inheritance is not evil by nature, and so is a goto statement, but they should be used cautiously. Anyway, this is a discussion for a software engineering SE and not here – Rsf Feb 16 '18 at 13:15
1

IMHO, I think there is a contradiction in

tasked to create some end2end / gui functional automated tests for the component itself and have been asked to try and make sure we don't have to write automated tests to cover it in each product which implements it

If you are creating E2E for the three products, then you need three tests for the imgae viewer. If the steer is not to do that and instead focus on one test, then as you point out, Image Viewer is no longer tested as part of E2E and would be a standalone test that hopefully covers the three uses of the component.

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.