
Today class, we learn about testing our code with Python in PyCharm!
Some preface, first
What’s Happening This Semester?
This semester starts another CS class that requires me to detail my exploration of the content outside of class. The class pertains to the testing and quality assurance of software, particularly with the Java language in the VSCode environment. However, as an avid hater of Java (and VSCode), I have been trying to do more projects in other languages, such as Python, C++, and other fringe languages.
With this choice to use other languages, I was curious as to how different the testing process is with other IDEs as well. Thus the choice of PyCharm.
Fine, I’ll Give you the Link
As a part of these blog posts, I am legally required to attach to it the resource I have found relating to our class topics. Luckily, PyCharm’s owner, JetBrains, has some wonderful documentation relating to many facets of their resource, especially on testing with their IDE.
This page walks a user through the basics of creating, organizing, and running their tests in PyCharm using python.
As a different language, the syntax for testing is obviously different, but it still makes sense and works in the general frameworks we went over in class
So… What Does Testing Look Like in Python?
Instead of Java’s JUnit setup, Python heavily leans on frameworks like pytest and the built-in unittest module. PyCharm supports both out of the box, which is convenience that is lacking with VSCode, which requires much more package installation to get started (which is a hassle).
At a high level, the workflow looks like this:
- Write your function
- Create a separate test file.
- Write functions that start with
test_. - Run them through PyCharm’s built-in test runner.
- Watch either green checkmarks appear or your ego collapse.
Identical to what we’re doing in Java in terms of structure and basic idea, but way cleaner. None of those messy parenthesis everywhere.
Relating This Back to Class Concepts
Even though the course centers on Java, the core ideas remain universal:
- Unit testing isolates behavior.
- Assertions validate expected outcomes.
- Automated test runners reduce manual verification.
- Failing tests are diagnostic tools, not personal attacks.
Switching languages helped reinforce that testing is not language-specific.
If anything, using Python clarified the underlying structure of what we’re learning. When you remove some of the verbosity, you see the skeleton of testing more clearly:
- Arrange
- Act
- Assert
That pattern shows up everywhere.
Until next time,
-Will
Leave a comment