Skip to main content

Return of Python Unittests

I got into the habit of using Python unit tests in a job a few about a year ago. I eventually created the jsonhunt.py unit test in my Toys repository but it stopped working. I haven't even used the jsonhunt script in a while and am no longer certain of its usefulness but I don't like the idea of not being able to do unit tests if I wanted to.

Simple working example

So I sat down and got a simple unit test working. Here's the test script:

Notes

  • I wish I had found a way to see options or arguments in the test but I couldn't find a way to do that. I had to settle for an environment variable to control the logging level.
  • From the job I mentioned, I remembered we had a way of specifying the log level through some sort of option but I couldn't find a opportunity to get such an option, even through the superclass.
  • At first I was trying to use a zero-argument constructor method but that wasn't working so I added *args, **vargs.

From the command line

I have a copy of the script in a git repository so a way to run the test is using that copy of the script:
  1. get clone https://github.com/pfuntner/fun.git
  2. cd fun/test
  3. python -m unittest test1.Tests.test1

From PyCharm

Using the same repository as above:
  1. Install the pytest package in PyCharm if it's not already installed
  2. Create a PyCharm Run Configuration using the pytest Python test template:

Notes

  • I couldn't get the PyCharm debugger working - at least not yet!
Labels:

Comments

Post a Comment

Popular posts from this blog

Python ArgParse

Maybe it's my use of the getopt() function in C/C++ but in my Python scripts, I've always just made do with the native getopt package and it's served me well. Over time, people have encouraged me to look at using ArgParse but I've always been kind of resistant because it was a little mysterious to me. I finally sat down and figured out how to do basic things I do a lot in scripts using getopt and worked up a simple script using ArgParse to do the same thing. There are definitely some advantages to ArgParse ! Here's the gist with this sample: I've made a few updates to the gist as I discover new features of which I want to take advantage: Mutually-exclusive options Script description etc. I will admit that since I've created this gist, I've been using ArgParse for new scripts. I can't whip out a script using ArgParse from memory yet (which I can do when I use getopt !) but it's becoming easier. I haven't gone back and...
Post a Comment
Read more

Dynamic Python script loading

I have a bunch of toys and tools in a Git repository - I affectionately call this my toys repo . Most are just scripts that I use from a Unix (Cygwin or Git bash on Windoze) command line but there are some Python classes that I sometimes use in another script. Today at work, I was coming up with a new Python script that made use of a couple of my public classes. The script is good enough to share with my colleagues but I'm faced with the problem of my public classes: I imagine that most of my colleagues haven't even heard of my public classes and I don't expect them to download the entire repo just to get a couple of classes If I'm going to distribute the classes as separate files I introduce new problems: It could be confusing to have the files tag along. What is the user supposed to do with them? The answer is nothing - they should leave them alone and make sure they are in the same directory as the main script in case they decide to move th...
1 comment
Read more

GNU date on Windoze

I love the Cygwin package on Windoze. I'm more of a Unix guy and can't stand the Windows command prompt. I much prefer a standard shell such as bash across all platforms. At my current job, I'm doing most of my development on Windows and our setup makes it so that I have to rely on Git bash more but I still have Cygwin installed and use it for things that aren't so tied to work. Git bash pisses me off sometimes with relation to copy and paste, especially inside the vi editor! What's up with that? So this post's focus is on the date command. One of my few peeves about Cygwin is the default behavior of the command on Windows: Tue, Apr 3, 2018 7:26:52 AM The whole reason for using Cygwin was to have a shell environment that looks and acts like Unix. This does not look like Unix. And GNU being what it is, Git bash works the same way! Yes, my OCD is obvious... some people might say Well, that's close but I don't like this behavior! Uni...
2 comments
Read more