Testing programs manually is natural; writing automated tests is not.
Programmers use various techniques when learning to code or when dabbling in new technologies and libraries. It is common to write short snippets, follow a tutorial, play in the REPL, or even use Jupyter (http://jupyter.org/). Often, this involves manually verifying the results of what is being studied by using print statements or plotting graphics. This is easy, natural, and a perfectly valid way of learning new things.
This pattern, however, should not be carried over to professional software development. Professional software is not simple; on the contrary, it is usually very complex. Depending on how well designed a system is, parts can be intertwined in strange ways, with the addition of new functionality potentially breaking another, apparently unrelated, part of the system. Fixing a bug might cause another bug to spring up somewhere else.
How can you make sure that a new functionality is working or that a bug has been squashed for good? Just as important, how can you ensure that, by fixing or introducing a new feature, another part of the system will not be broken?
The answer is by having a healthy and embracing suite of automated tests, also called a test suite.
A test suite is, simply put, code that tests your code. Usually, they create one or more necessary resources and call the application code under test. They then assert that the results are as expected. Besides being executed on the developer's machine, in most modern setups, they are run continuously—for example, every hour or every commit—by an automated system such as Jenkins. Because of this, adding tests for a piece of code means that, from now on, it will be tested again and again as features are added and bugs are fixed.
Having automated tests means that you can make changes to a program and immediately see if those changes have broken part of the system, acting as a safety net for developers. Having a good test suite is very liberating: you no longer fear improving a piece of code that was written 8 years ago, and if you make any mistakes, the test suite will tell you. You can add a new feature and be confident that it will not break any other parts of the system that you did not expect. It is absolutely essential to be able to convert a large library from Python 2 to 3 with confidence, or make large-scale refactorings. By adding one or more automated tests that reproduce a bug, and prove that you fixed it, you ensure the bug won't be reintroduced by refactoring or another coding error later down the road.
Once you get used to enjoying the benefits of having a test suite as a safety net, you might even decide to write tests for APIs that you depend on but know that developers don't have tests for: it is a rare moment of professional pride to be able to produce failing tests to the original developers to prove that their new release is to blame for a bug and not your code.
Having a well written and in-depth test suite will allow you to make changes, big or small, with confidence, and help you sleep better at night.
