{"id":1922,"date":"2019-06-04T17:18:39","date_gmt":"2019-06-04T16:18:39","guid":{"rendered":"https:\/\/rosetta.vn\/short\/?p=1922"},"modified":"2019-06-04T17:18:39","modified_gmt":"2019-06-04T16:18:39","slug":"getting-started-with-testing-in-python-real-python","status":"publish","type":"post","link":"https:\/\/rosetta.vn\/short\/2019\/06\/04\/getting-started-with-testing-in-python-real-python\/","title":{"rendered":"Getting Started With Testing in Python \u2013 Real Python"},"content":{"rendered":"

This tutorial is for anyone who has written a fantastic application in Python but hasn\u2019t yet written any tests.<\/p>\n

Testing in Python is a huge topic and can come with a lot of complexity, but it doesn\u2019t need to be hard. You can get started creating simple tests for your application in a few easy steps and then build on it from there.<\/p>\n

In this tutorial, you\u2019ll learn how to create a basic test, execute it, and find the bugs before your users do! You\u2019ll learn about the tools available to write and execute tests, check your application\u2019s performance, and even look for security issues.<\/p>\n

\n

Free Bonus:<\/strong>\u00a05 Thoughts On Python Mastery<\/a>, a free course for Python developers that shows you the roadmap and the mindset you’ll need to take your Python skills to the next level.<\/p>\n<\/div>\n

Testing Your Code<\/h2>\n

There are many ways to test your code. In this tutorial, you\u2019ll learn the techniques from the most basic steps and work towards advanced methods.<\/p>\n

Automated vs. Manual Testing<\/h3>\n

The good news is, you\u2019ve probably already created a test without realizing it. Remember when you ran your application and used it for the first time? Did you check the features and experiment using them? That\u2019s known as\u00a0exploratory testing<\/strong>\u00a0and is a form of manual testing.<\/p>\n

Exploratory testing is a form of testing that is done without a plan. In an exploratory test, you\u2019re just exploring the application.<\/p>\n

To have a complete set of manual tests, all you need to do is make a list of all the features your application has, the different types of input it can accept, and the expected results. Now, every time you make a change to your code, you need to go through every single item on that list and check it.<\/p>\n

That doesn\u2019t sound like much fun, does it?<\/p>\n

This is where automated testing comes in. Automated testing is the execution of your test plan (the parts of your application you want to test, the order in which you want to test them, and the expected responses) by a script instead of a human. Python already comes with a set of tools and libraries to help you create automated tests for your application. We\u2019ll explore those tools and libraries in this tutorial.<\/p>\n

Unit Tests vs. Integration Tests<\/h3>\n

The world of testing has no shortage of terminology, and now that you know the difference between automated and manual testing, it\u2019s time to go a level deeper.<\/p>\n

Think of how you might test the lights on a car. You would turn on the lights (known as the\u00a0test step<\/strong>) and go outside the car or ask a friend to check that the lights are on (known as the\u00a0test assertion<\/strong>). Testing multiple components is known as\u00a0integration testing<\/strong>.<\/p>\n

Think of all the things that need to work correctly in order for a simple task to give the right result. These components are like the parts to your application, all of those classes, functions, and modules you\u2019ve written.<\/p>\n

A major challenge with integration testing is when an integration test doesn\u2019t give the right result. It\u2019s very hard to diagnose the issue without being able to isolate which part of the system is failing. If the lights didn\u2019t turn on, then maybe the bulbs are broken. Is the battery dead? What about the alternator? Is the car\u2019s computer failing?<\/p>\n

If you have a fancy modern car, it will tell you when your light bulbs have gone. It does this using a form of\u00a0unit test<\/strong>.<\/p>\n

A unit test is a smaller test, one that checks that a single component operates in the right way. A unit test helps you to isolate what is broken in your application and fix it faster.<\/p>\n

You have just seen two types of tests:<\/p>\n

    \n
  1. An integration test checks that components in your application operate with each other.<\/li>\n
  2. A unit test checks a small component in your application.<\/li>\n<\/ol>\n

    You can write both integration tests and unit tests in Python. To write a unit test for the built-in function\u00a0sum()<\/code>, you would check the output of\u00a0sum()<\/code>\u00a0against a known output.<\/p>\n

    For example, here\u2019s how you check that the\u00a0sum()<\/code>\u00a0of the numbers\u00a0(1, 2, 3)<\/code>\u00a0equals\u00a06<\/code>:<\/p>\n

    >>><\/span><\/p>\n
    >>> <\/span>assert<\/span> sum<\/span>([<\/span>1<\/span>,<\/span> 2<\/span>,<\/span> 3<\/span>])<\/span> ==<\/span> 6<\/span>,<\/span> \"Should be 6\"<\/span>\r\n<\/pre>\n<\/div>\n
    This will not output anything on the REPL because the values are correct.<\/p>\n
    If the result from\u00a0sum()<\/code>\u00a0is incorrect, this will fail with an\u00a0AssertionError<\/code>and the message\u00a0\"Should be 6\"<\/code>. Try an assertion statement again with the wrong values to see an\u00a0AssertionError<\/code>:<\/p>\n
    >>><\/span><\/p>\n
    >>> <\/span>assert<\/span> sum<\/span>([<\/span>1<\/span>,<\/span> 1<\/span>,<\/span> 1<\/span>])<\/span> ==<\/span> 6<\/span>,<\/span> \"Should be 6\"<\/span>\r\nTraceback (most recent call last):<\/span>\r\n  File \"<stdin>\"<\/span>, line 1<\/span>, in <module><\/span>\r\nAssertionError<\/span>: Should be 6<\/span>\r\n<\/pre>\n<\/div>\n
    In the REPL, you are seeing the raised\u00a0AssertionError<\/code>\u00a0because the result of\u00a0sum()<\/code>\u00a0does not match\u00a06<\/code>.<\/p>\n
    Instead of testing on the REPL, you\u2019ll want to put this into a new Python file called\u00a0test_sum.py<\/code>\u00a0and execute it again:<\/p>\n
    \n
    def<\/span> test_sum<\/span>():<\/span>\r\n    assert<\/span> sum<\/span>([<\/span>1<\/span>,<\/span> 2<\/span>,<\/span> 3<\/span>])<\/span> ==<\/span> 6<\/span>,<\/span> \"Should be 6\"<\/span>\r\n\r\nif<\/span> __name__<\/span> ==<\/span> \"__main__\"<\/span>:<\/span>\r\n    test_sum<\/span>()<\/span>\r\n    print<\/span>(<\/span>\"Everything passed\"<\/span>)<\/span>\r\n<\/pre>\n<\/div>\n
    Now you have written a\u00a0test case<\/strong>, an assertion, and an entry point (the command line). You can now execute this at the command line:<\/p>\n
    \n
    $<\/span> python test_sum.py\r\nEverything passed<\/span>\r\n<\/pre>\n<\/div>\n
    You can see the successful result,\u00a0Everything passed<\/code>.<\/p>\n
    In Python,\u00a0sum()<\/code>\u00a0accepts any iterable as its first argument. You tested with a list. Now test with a tuple as well. Create a new file called\u00a0test_sum_2.py<\/code>\u00a0with the following code:<\/p>\n
    \n
    def<\/span> test_sum<\/span>():<\/span>\r\n    assert<\/span> sum<\/span>([<\/span>1<\/span>,<\/span> 2<\/span>,<\/span> 3<\/span>])<\/span> ==<\/span> 6<\/span>,<\/span> \"Should be 6\"<\/span>\r\n\r\ndef<\/span> test_sum_tuple<\/span>():<\/span>\r\n    assert<\/span> sum<\/span>((<\/span>1<\/span>,<\/span> 2<\/span>,<\/span> 2<\/span>))<\/span> ==<\/span> 6<\/span>,<\/span> \"Should be 6\"<\/span>\r\n\r\nif<\/span> __name__<\/span> ==<\/span> \"__main__\"<\/span>:<\/span>\r\n    test_sum<\/span>()<\/span>\r\n    test_sum_tuple<\/span>()<\/span>\r\n    print<\/span>(<\/span>\"Everything passed\"<\/span>)<\/span>\r\n<\/pre>\n<\/div>\n
    When you execute\u00a0test_sum_2.py<\/code>, the script will give an error because the\u00a0sum()<\/code>\u00a0of\u00a0(1, 2, 2)<\/code>\u00a0is\u00a05<\/code>, not\u00a06<\/code>. The result of the script gives you the error message, the line of code, and the traceback:<\/p>\n
    \n
    $<\/span> python test_sum_2.py\r\nTraceback (most recent call last):<\/span>\r\n  File \"test_sum_2.py\", line 9, in <module><\/span>\r\n    test_sum_tuple()<\/span>\r\n  File \"test_sum_2.py\", line 5, in test_sum_tuple<\/span>\r\n    assert sum((1, 2, 2)) == 6, \"Should be 6\"<\/span>\r\nAssertionError: Should be 6<\/span>\r\n<\/pre>\n<\/div>\n
    Here you can see how a mistake in your code gives an error on the console with some information on where the error was and what the expected result was.<\/p>\n
    Writing tests in this way is okay for a simple check, but what if more than one fails? This is where test runners come in. The test runner is a special application designed for running tests, checking the output, and giving you tools for debugging and diagnosing tests and applications.<\/p>\n
    Choosing a Test Runner<\/h3>\n
    There are many test runners available for Python. The one built into the Python standard library is called\u00a0unittest<\/code>. In this tutorial, you will be using\u00a0unittest<\/code>\u00a0test cases and the\u00a0unittest<\/code>\u00a0test runner. The principles of\u00a0unittest<\/code>\u00a0are easily portable to other frameworks. The three most popular test runners are:<\/p>\n