1

Scenario:

  • Our CLI-script downloads data
  • Therefore, amongst other things such as pre/postprocessing, it calls a function from another (internal) python package (which is maintained by another group)
  • The internal python package finally executes a request to an (internal) web server

In order to test the download-data function we could mock three different things:

  • nothing, i.e. actually download data from the server.
  • the executed request (by intercepting it).
  • the function from the other python package

Obviously, the first choice is the most comprehensive test, but it can easily fail due to external factors (changes/errors in python package or not running webserver). The last choice is the most "robust" one in the sense that it really only tests the CLI-script. So there are PROs and CONs to each choice.

Improve this question

2 Answers 2

Reset to default
1

I would say that it depends on the kind of test you want to apply.

An Unit-Test would test just the CLI script and not the called package. Therefore there you would mock the function of the external package.
If you do not trust that package, then you could write additional Unit-Tests to test just the function of that package.

If you want to write integration tests, then i would intercept the request.

If your CLI Script is really nothing more than calling the external package with a simple parameter, then that code is so obvious, that it is a thought to not test it at all.

As with all tests the question is what you want to achieve. If you want to be sure that your script will send the right request and you do not trust that external package, then a integration test may may be your best approach.
If you think that that external package is trustworthy (because its used a lot, good maintained, etc etc), then i would just think about testing the CLI Script.

And if you want the full programm, you could write Unit-Tests for your CLI (with the mocked function), Unit Tests for the external function and last but not least an integration test...

And there´s the point for me. If this functionality is the very holy grail of my application, then i would think about investing all that effort. But in general i would just test MY code (the CLI) and mock the external stuff. Why did i choose that external dependency if i do not trust it?
Okay, sometimes i write Unit-Tests for external stuff, but thats mostly for learning how to use it.

Improve this answer
1

I think it helps to answer your question to understand the purpose of mocking and unit tests. The idea behind unit tests is to test the unit you built, and the idea behind mocks are to isolate your tests from things that can go wrong.

It's not a bad idea to have integration tests which do test end to end communications--if you can do it in a way that won't generate bad data in a production environment in either system.

That said, it is a good idea to isolate your unit tests from things that can go wrong with services and code you don't directly control in your tests. That leaves two options to generate mocks:

  • Protocol layer: the executed request
  • Logical layer: the function being called by your code

Since unit tests are intended to only exercise the code you wrote, my recommendation is to mock at the logical layer. In other words, mock the library you are calling.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.