I don't want to spam you with a ton of code, but please have a quick look at this boiler-plate method:
In this scenario let's say I have a ProcessingText.py
file (class) that I finished its unit testing, including the methods setTextToClean(text)
and getCleanedText()
.
And I have another file, UI.py
(a class also), that has the following handle_text(text)
:
UI.py
# UI Class
def handle_text(self, res):
self.processingTextObj.setTextToClean(res)
return self.processingTextObj.getCleanedText()
The Question:
- Looking at that method, to me, I believe that time-wise, this makes more sense to be integration-tested. If I were to unit test it, I would mock the
processingTextObj
along with the two used methods, but would that be advisable? Just for the sake of not leaving any method without being unit-tested?
I've used mocking before for decoupling dependencies while unit-testing, but it made sense before because what have been mocked were just some parts, where a bit of logic in the actual method remained. Here, for this method, I can't see a point in unit testing.
NOTE
My plan was to create a unit-test AND an integration-test scripts for ProcessingText.py
and for UI.py
as well (since both of them have external dependencies within each class methods), is this approach wrong? and if handle_text()
didn't need any unit-testing, I would still need to write an integration test for it, correct? (I know that I should not be asking more than one question, my bad)
Please correct my understanding if I'm wrong.
Thank you for your time.
setTextToClean
should be the method being unit tested, nothandle_text
. handle_text is just a pass-through method; it doesn't contain any logic, so there is no need to unit-test it.setTextToClean
as I mentioned, does that I mean that theUI.py
should not have any unit-testing scripts? and should I integration-test it (specificallyhandle_text
) ?