4

I'm writing a number of Selenium test classes that use Helper classes which contain processes that are often reused (ie. accessing a particular page, entering something into a specific field, etc.)

Currently these Helper classes are instantiated in a BasicTest class which every test class extends.

I was thinking about using dependency injection to instantiate the Helperclasses, but I'm not sure if it's pertinent in this case? I know there will only ever be one definition of each Helper class, so would it still be a plus to instantiate them with dependency injection, or would it just be pointless work that complicates the project for no reason?

4
  • 2
    Beware the "only ever" argument! The entire point of software engineering is to manage the risk of unforeseen change requests. Commented Jan 23, 2020 at 8:54
  • Does the Helper class contain any state, or it can be a bunch of static methods?
    – max630
    Commented Jan 23, 2020 at 12:06
  • @max630 the Helper classes only contain non-static methods
    – Grumbunks
    Commented Jan 23, 2020 at 12:34
  • normally i'd say you always have an extra implementation in the test but if these are only test classes anyway this may be a case for DAMP > DRY
    – jk.
    Commented Jan 23, 2020 at 13:25

2 Answers 2

5

It sounds like you know that it would be best practice, but you don't know if its worth the effort.

Leaving DI and the specifics of your case aside, here are my "Should I Bother With It?" rules, or SIBWI for short.

  1. Does it actually cost any extra time to implement?
  2. Am I the Kwisatz Haderach?
  3. Do I want to learn new things?
  4. Do I want to be able to say that I followed best practice?
  5. Am I being lazy?
  6. How long will this code exist for?

I find that in almost all cases the answers are

  1. No
  2. No
  3. Yes
  4. Yes
  5. Maybe
  6. Years

And I follow best practice

3
  • +1 for Number 2
    – keuleJ
    Commented Jan 23, 2020 at 9:34
  • 1
    Okay, but what if I am Kwisatz Haderach, does that mean I can skip doing this or should I worry about future developers developing resistance to my future sight and still follow the best practices?
    – Maurycy
    Commented Jan 23, 2020 at 10:17
  • if you are the Kwisatz Haderach you know the dangers of the "safe path"
    – Ewan
    Commented Jan 23, 2020 at 10:24
4

The reason you use dependency injection is to promote software reuse and extensibility. If you have a class method whose argument is an interface, you are telling the world "give me anything so long as the particular instance implements this interface".

If, however, your code is made to work for one type of implementation reliably (i.e. the class expects only one implementation of helper, -- ever -- then consider changing the argument to the implementing class type instead.

But once you have programmed to an implementation -- and not an interface -- you are now bound by this decision moving forward.

In short, be careful to consider your method signatures, especially when designing new API, as once these are defined, they will be expected to work this way by your clients.

Expecting clients to change their code simply because the API has changed is a bad thing (sadly, it happens far too often)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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