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?

  • 2
    Beware the "only ever" argument! The entire point of software engineering is to manage the risk of unforeseen change requests. Jan 23 '20 at 8:54
  • Does the Helper class contain any state, or it can be a bunch of static methods?
    – max630
    Jan 23 '20 at 12:06
  • @max630 the Helper classes only contain non-static methods
    – Grumbunks
    Jan 23 '20 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.
    Jan 23 '20 at 13:25

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

  • +1 for Number 2
    – keuleJ
    Jan 23 '20 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
    Jan 23 '20 at 10:17
  • if you are the Kwisatz Haderach you know the dangers of the "safe path"
    – Ewan
    Jan 23 '20 at 10:24

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, privacy policy and cookie policy

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