1

Currently, I am creating some end to end tests for an API and have a method that would be perfect to use for a test except for the fact that it has a return type of void. If I were to change the return type to List, could this possibly break existing functionality somewhere within the system? My current thoughts are that all code that calls the method will not be affected as they are not using the method to assign any value to a variable. Are there any cases in which this is not true?

This is for a legacy code base, so unfortunately I am stuck with it. The codebase is too vast for me to look up all instances of code that could be affected by this change.

TallTed
  • 9,069
  • 2
  • 22
  • 37
tomcorlett
  • 13
  • 4
  • 1
    If you're testing a `void` method, it can be assumed that the method has side-effects, which means that you're supposed to be testing if those side-effects happen correctly, e.g. using a Mock object. Changing the method to return something will not verify those side-effects happen, which means that your test is incomplete. As such, changing the method is not the right solution. – Andreas Jul 09 '19 at 18:27
  • I know this is isn't the ideal way to go about it, but I'm testing an API call to a client's endpoint, and then assessing if their response is correct. So if I know that all variables that are sent to the clients endpoint are correct, and that the client's response is not changed in any way before the end of the method, is this a valid way of implementing the test? – tomcorlett Jul 09 '19 at 18:39
  • Possible duplicate of [Retrofitting void methods to return its argument to facilitate fluency: breaking change?](https://stackoverflow.com/questions/3589946/retrofitting-void-methods-to-return-its-argument-to-facilitate-fluency-breaking) – jaco0646 Jul 17 '19 at 00:05

1 Answers1

0

You're right. You can easily change the return type from void to another object since it could never be used before.

Arthur S.
  • 482
  • 2
  • 8
  • 25