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 Class
 def handle_text(self, 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.


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.

  • 1
    setTextToClean should be the method being unit tested, not handle_text. handle_text is just a pass-through method; it doesn't contain any logic, so there is no need to unit-test it. – Robert Harvey Dec 13 '20 at 15:20
  • @RobertHarvey I've already unit-tested setTextToClean as I mentioned, does that I mean that the UI.py should not have any unit-testing scripts? and should I integration-test it (specifically handle_text) ? – Ahmed Alhallag Dec 13 '20 at 15:30
  • I don't generally unit-test methods that don't contain any logic. – Robert Harvey Dec 13 '20 at 15:31
  • Does this answer your question? Do I need unit test if I already have integration test? – gnat Dec 13 '20 at 16:15

Your handle text function is just calling another function in processing text object so it is not worth testing in unit and integration.

You instead test processing text functions (set text to clean in your code) in unit test, and the entrypoint of the ui class.

  • the entry method of the ui class is to be integration-tested, correct? – Ahmed Alhallag Dec 13 '20 at 21:28
  • @AhmedAlhallag that's correct – user3153970 Dec 13 '20 at 22:38

Unit test is helpful to verify your code path in individual component works as you expect, and it is faster to locating the potential bugs in smaller piece. Here there may be two parts that worth (unit) testing:

  • The logic inside setTextToClean, in which you assert some fields are expected after this set method is being called,
  • The logic in your code somewhere (a method A) that handle_text is properly called, in which you verify either handle_text or setTextToClean is being invoked x times as the logic inside A expects.

Another thing worth testing in unit test is to verify the capability of handling several code paths other than happy case (e.g., how the exception case is addressed and handled by the code logic within individual component).

Integration test verifies several components (external dependencies of your UI and processingText as you mentioned ) are working together as expected. In your case it verifies the UI workflow responses correctly with the input request rather than tests on a specific passing-through method .

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.