Skip to main content

Testing In Python...and my Two cents

The only lesson I have learned in mys past one and half of years of experience in testing is that the easier I make writing and running tests for my programs, the faster I can produce bug-free software.

Being a developer and also being a tester can do wonders I think. Never before this thought would have crossed my mind while coding.

That is why I start most projects nowadays with two pre-baked files: and
With this setup and tools like Nose, testing code in Python for me is nearly pain free. Recently however, I notice one aspect of the unittest package in Python's standard libary drives me absolutely crazy:
Why is there no simple method to run a single test case from within an interactive python shell?
As developers, this is important because if we are going to make writing tests an integral part of our development workflow, one needs some way to actually run the damn test without dropping out of our Python sessions and breaking out of our mental flow.
Being forced to run tests solely from the commandline also means we can't take advantage of features like ipython's ability to automatically drop into a pdb debugging session when an error occurs. This is extremely useful for when you want to introspect one or two variables to determine why a test failure occurred.
In general, it seems like the unittest library's lack of a simple function to run single test cases in an interactive shell dis-incentivizes programmers from writing tests and detracts from python's whole "rapid iteration" ethos.
After googling around and failing to find any good alternatives, I've finally settled on writing my own utility function to run single test cases:

def runtest(testCase, methodName):
    """ Runs a test case from within interactive shell """

    tc = testCase(methodName)
    getattr(tc, "setUp", lambda:None)()
        getattr(tc, methodName)()  
        getattr(tc, "tearDown", lambda:None)()

I add this function to every single project that I create now, and the qualitative feel of writing tests just feels so much more natural now. I also find myself writing more tests and running them more often with this function in my projects.
Give it a try, and let me know whether this has any effect for you. I'd love to hear your feedback on how it affects your development workflow.


Popular posts from this blog

Visualizing large scale Uber Movement Data

Last month one of my acquaintances in LinkedIn pointed me to a very interesting dataset. Uber's Movement Dataset. It was fascinating to explore their awesome GUI and to play with the data. However, their UI for exploring the dataset leaves much more to be desired, especially the fact that we always have to specify source and destination to get relevant data and can't play with the whole dataset. Another limitation also was, the dataset doesn't include any time component. Which immediately threw out a lot of things I wanted to explore. When I started looking out if there is another publicly available dataset, I found one at Kaggle. And then quite a few more at Kaggle. But none of them seemed official, and then I found one released by NYC - TLC which looked pretty official and I was hooked.
To explore the data I wanted to try out OmniSci. I recently saw a video of a talk at jupytercon by Randy Zwitch where he goes through a demo of exploring an NYC Cab dataset using OmniSci. A…

ARCore and Arkit: What is under the hood : Anchors and World Mapping (Part 1)

Reading Time: 7 MIn
Some of you know I have been recently experimenting a bit more with WebXR than a WebVR and when we talk about mobile Mixed Reality, ARkit and ARCore is something which plays a pivotal role to map and understand the environment inside our applications.
I am planning to write a series of blog posts on how you can start developing WebXR applications now and play with them starting with the basics and then going on to using different features of it. But before that, I planned to pen down this series of how actually the "world mapping" works in arcore and arkit. So that we have a better understanding of the Mixed Reality capabilities of the devices we will be working with.
Mapping: feature detection and anchors Creating apps that work seamlessly with arcore/kit requires a little bit of knowledge about the algorithms that work in the back and that involves knowing about Anchors. What are anchors: Anchors are your virtual markers in the real world. As a develope…

ARCore and Arkit, What is under the hood: SLAM (Part 2)

In our last blog post (part 1), we took a look at how algorithms detect keypoints in camera images. These form the basis of our world tracking and environment recognition. But for Mixed Reality, that alone is not enough. We have to be able to calculate the 3d position in the real world. It is often calculated by the spatial distance between itself and multiple keypoints. This is often called Simultaneous Localization and Mapping (SLAM). And this is what is responsible for all the world tracking we see in ARCore/ARKit.
What we will cover today:How ARCore and ARKit does it's SLAM/Visual Inertia OdometryCan we D.I.Y our own SLAM with reasonable accuracy to understand the process better Sensing the world: as a computerWhen we start any augmented reality application in mobile or elsewhere, the first thing it tries to do is to detect a plane. When you first start any MR app in ARKit, ARCore, the system doesn't know anything about the surroundings. It starts processing data from cam…