testing

A Better AsyncTestCase for Python

If you need asynchronous support in python unit tests, there are a few possibilities.  A simple google search points you to a few packages, one being tornado.  Tornado’s tornado.testing.AsyncTestCase seems straight-forward.  However it does have a shortcoming: it’s not thread-safe.  Trying to use it with a thread will result in a sporadic exception.  Consider this thread-safe, functionally similar alternative.

from threading import Event
from unittest import TestCase


class TimeoutError(Exception):
    pass


class AsyncTestCase(TestCase):
    """ Provides functionality similar to tornado.testing.AsyncTestCase except is thread-safe.
    """
    def __init__(self):
        self._done = Event()
    
    def setUp(self):
        super(AsyncTestCase, self).setUp()
        self._done.clear()

    def tearDown(self):
        super(AsyncTestCase, self).tearDown()
        self._done.clear()

    def wait(self, timeout=None):
        """ Wait for event to be set.  Raise an exception if the event isn't set by the timeout.
        """
        if timeout is None:
            timeout = get_async_test_timeout()

        self._done.wait(timeout)

        if not self.is_done():
            raise TimeoutError()
        
    def stop(self):
        """ Set the event to terminate wait.
        """
        self._done.set()
    
    def is_done(self):
        return self._done.isSet()

# taken from tornado.
def get_async_test_timeout(default=5):
    """Get the global timeout setting for async tests.
    Returns a float, the timeout in seconds.
    """
    try:
        return float(os.environ.get('ASYNC_TEST_TIMEOUT'))
    except (ValueError, TypeError):
        return default

 

 

 

Posted by Chad Dotson in Doing Things Better, Programming, 0 comments

Notes On Writing Testable JavaScript Vol 1

When writing JavaScript, I am a big fan of minimizing functionality and variables exposed publicly, which we all know to be good practice. However, this leads to anonymous functions and functions hidden within closures.  So….

How Do You Test That?

How exactly do you test private methods in JavaScript?  To answer that you should ask yourself, should I even be testing them independently or can I write tests for the exposed functionality and still achieve code coverage?  If the answer to that question is “yes,” write tests for the exposed functionality that inherently test the underlying private functions and stop there.  If the answer is “no, I really need to test this function.”  There are a few approaches.

Member Variables For Testing Only

This approach involves creating member variables intended for testing and testing alone.  This method relies on the build process to remove the variables before going to production.  While this process works, I believe it has a code smell to it.  You are polluting and bloating the code base with needless variables.  If you are interested in the approach, here is an article about it.

The Real Question: Should It Be There?

Is the fact that you are asking this question an indicator of a code design issue?  Perhaps the code is in violation of the Single Responsibility Principle?  I’ve recently experienced a little epiphany associated with this.  I realized that a collection of private functions that I was hiding actually belonged to a separate object as public functions.  This refactoring drastically reduced the code complexity, made it more maintainable, and enabled small, important functions to be separately tested.

 

 

 

 

 

Posted by Chad Dotson in Programming, 1 comment