Yesterday I thought it was finally time to try an IDE (Integrated Development Environment. I downloaded PyCharm Community (free) which many friends use and recommend.
What’s an IDE?
An IDE in an integrated development environment. It contains tools that make developers’ lives easier. PyCharm, an IDE for Python, contains a source code editor with code refactoring, build automation tools, a debugger, a console (command line / Terminal) and a Python interpreter. You can run tests (e.g. unit tests and doctests) with one keyboard shortcut. There’s also integrated version control.
Why use an IDE?
Using an IDE can (1) save you time by giving you quick access to enabling tools and (2) improve your code quality by giving you recommendations and shortcuts for code refactoring. What’s refactoring? If you forgot a colon after your if statement, if you didn’t adhere to the Python PEP style guide (e.g. by leaving only one blank row between functions instead of two) or if PyCharm thinks your code has typos, it’ll give you warnings and recommendations.
I find an IDE like PyCharm especially good for beginners because (1) it gives you code refactoring recommendations and (2) makes it easier to write and run tests, which is a good habit to get into.
Tests are important because they check that your code is running properly. They are particularly useful for checking changes to one part of a complex application don’t have unintended side effects or to check that corner cases are covered. (Writing tests also helps with documentation among many other things. For more on testing, check out this page from the Hitchhiker’s Guide to Python. I enjoyed reading it.)
Doctests are tests included within commented documentation. Doctests seem to be better for short examples because they’re easier to set up and you get free documentation. But for anything beyond a few basic examples, you should use other tests (e.g. unit tests) to supplement doctests. You don’t want to include ten corner cases and tests for each of the twenty functions you’ve written in your on-page documentation.
Unit Tests (When not to use Doctests)
Examples of cases where you’d definitely not want to use only doctests would be any of the LinkedList problem tests, which involve constructing a linked list and applying a function (e.g. return the kth to last node in the linked list) to the head node of the linked list and asserting that the result equals the expected result. If the result doesn’t equal the expected result, we will get an error.
The reason this can’t be done with a doctest elegantly is because it involves many lines of code. This would clog up the documentation and may confuse readers. There may also be a larger number of relevant cases to check.
- Unit test function names have to start with test.
- Run -> Edit Configurations -> ‘check only subclasses’ has to be checked.
- Don’t name your Python files with hyphens. It’ll cause problems if you try to import functions from that file (i.e. treat it as a package).