Hello Koji devel,
I am trying get pull request #2979 "Add utility function to watch builds" ready [1]. Functionally, everything is clear enough now, but I have a problem with regression tests. I can come up with more than one way to handle them, but I cannot determine which of my options would be right choice for this code base. A description of the situation follows with the options I have thought of. Guidance for choosing which one to pursue would be welcome.
For background, I am aiming for improving fedpkg so that I would wait for buildroot overrides it creates. The correct wait behavior is already implemented in 'koji wait-repo', but apart from running that as a separate process, is not usable from fedpkg code. My pull request simply splits the needed wait implementation to a separate, importable function. The change is quite simple as such.
The test suite already has a tests for the 'koji wait-repo' handler. Now that a major section of that call is moved to a library function, how should that new function be tested? The options I have considered are:
1. No new tests are needed. The existing 'koji wait-repo' handler test already tests the new function, albeit indirectly.
2. New tests are written for the new function. These will naturally have a large overlap with the existing tests. Let it be so — this is what happens when a handler for a cli command calls an importable function.
3. New tests are written for the new function, but to avoid duplication, the old tests are adapted to mock the new function with @patch. This has the advantages of both testing everything and avoiding duplication, at the cost of making everything more indirect by introducing more mocks. This method also does not seem have previous use in the code base. The mocking examples I find are all about external dependencies: session, stdout, time and such.
Any thoughts?
Regards, Otto
koji-devel@lists.stg.fedorahosted.org