As an exercise, though, I recommend bug hunting this code using only print debugging.It’s good practice and will force you to think of all the ways to use the console to alert you about different things happening in the code.Repeatability and isolation are key to these kinds of tests, even though we are still continuing with our theme of comparing expected outputs to actual outputs.Now that you have an understanding of unit testing overall, you can take a quick detour and see how to unit test Flask applications with the minimum viable test suite.When you run this either in your IDE with a test configuration or with in the CLI you’ll get…errors! Let’s fix it using the following exercise–the practical experience is invaluable, and putting what you read into practice will make it easier to recall in the future. Because we are only testing a single unit of code, we don’t really care about what other function calls do. Let’s add an outside function call to so instead we’ll make a mock in our test script.The mock will catch this call and return whatever you set the mock to return.
They help when you know roughly where errors are happening but can’t figure out why, and they give you a nice top-down view of everything happening inside your application at once.In all these situations and more, you will need to learn and get comfortable with the various methods for testing a Python CLI application.While the tooling choices can be intimidating, the main thing to keep in mind is that you’re just comparing the outputs your code generates to the outputs you expect. In this tutorial you’ll learn four hands-on techniques for testing Python command-line apps: Everything will be structured around a basic Python CLI app that passes data in the form of a multi-level dictionary to two functions that transform it in some way, then prints it to the user.You will essentially be writing a script or group of scripts that test each method with different inputs to ensure every logic branch within each method is tested–this is referred to as code coverage, and usually you want to aim for 100% code coverage.
This isn’t always necessary or practical, but we can save that for another article (or a textbook).
Rather than get into implementation-specific details of all available debuggers, in this section I’ll show you how to use debuggers with common functions, such as setting .