That is to say: do one thing, do it well.

Decorators (not to be confused with the decorator pattern) can add behaviors or side-effects to a method, and this can be dangerous. It seems harmless, because by adding a decorator, you’re likely taking boilerplate code and shuffling it elsewhere. However, they often encourage badness because of how easy it is to add these behaviors.

On testing decorated methods:

Adding an @decorator to a python object unarguably makes the undecorated code difficult to test in isolation. Decorators are applied at compile-time, and cannot be mocked or made to not-execute without some pain.

There are certainly a few common tricks that can help test a decorated method with minimal side-effects, but they require changes to the decorator itself. There’s just plain and simple no way to un-decorate a method for isolated testing.

Let’s look at a few common examples:

@expose: register a URL for a view function in a web framework

class BlogPostController(object):
    @expose("/blog/{post_id}")
    def index(self, request, post_id=None):
        """ show a blog post """
        post = adapter.get_post(post_id)
        return render("show_entry.html", dict(post=post))

Without the `@expose`, your `show_entry` knows how to get a given post and render it in the proper template. With the decorator, it also now knows which URL corresponds to that. You now have multiple reasons for this block of code to change, including pointing to a different URL or using a different template. It’s preferred to have a separate module for managing which urls point to which views.

Harm factor: low. Ick factor: medium – high.

@cache: try to get the result from memcache, otherwise, execute the function and stick it in cache for next time

class PostAdapter(DataAdapter):
    @cache
    def get_post(self, post_id)
        """ grab a blog post from the database """
        return self.query(Post).filter(id=post_id).one() # SQLAlchemy folks need to talk to Mr Demeter...

OK this seems cool right? You only hit the database when you have to, otherwise we get it even quicker by looking it up in the cache.

What happens if you want to disable caching? A separate cache abstraction layer would reduce volatility in your data adapter.

And what does the unit test look like?

class TestGettingAPost(object):
    def setup(self):
        self.query = Mock() #don't hit the production database!
        self.post_adapter = PostAdapter(query=self.query)
    def test_getting_a_post(self):
        assert self.post_adapter.get_post(123)

Damn, there’s no way to mock out the @cache decorator so it doesn’t run. Try to, I dare you. You’re likely going to actually get post 123 from your production memcache. Crappy. The only thing you can do is make the @cache grab the cache implementation from the PostAdapter instance (and mock that out in you test), or find some other sneaky way of disabling caching for test runs. But the @cache decorator isn’t all self-contained and fun anymore.

Harm factor: medium – high.

@validate: Make sure the request matches the specified schema, otherwise hand-off to error handler

class EditPostController(object):
    def _save_error(self, request, errors):
        """ @validate decorator kicked flow here, redisplay edit page with errors """
        ...
    @validate(schema, error_handler=_save_error)
    def save(self, request)
        post = self.schema.to_python(request.params)
        self.post_adapter.save_post(post)
        return redirect("/blog/{0}".format(post_id))

Without this @validate, there would be a lot of boilerplate code inside the `save` method. With it, any unit test for the save method will be likely linked to your schema. You’d have to make an actual valid request in order to test this method. That’s outside of any tests for your schema directly. That means double-coverage but 2 tests to update when requirements shift.

Harm factor: low-medium

Conclusions (or tl;dr):

As easy as it is to become infatuated with Python decorators, they definitely encourage you to violate the SRP. This can create a myriad of problems:

• Difficultly in isolating system under test
• Added complexity to enable testing
• Redundant redundant unit tests
• Making a code module more volatile than it ought to

They still have some valid use cases and can lead to cleaner code, however, as Master Yoda once said, “when you look at the dark side, careful you must be…”

Sometimes, you’d like to test actual file handling in a unit test. If you do, you should provide a sample data set packaged with your code in a data directory within your test directory.

Your package would then resemble the following structure:

/package
    /tests
        /data
            data.txt
        __init__.py
        test_module.py
    __init__.py
    module.py

In your test, you’ll need to provide a relative path to the data file. To do this, use the special __file__ attribute of the package to provide a starting point. This will let you know where the module lives on disk regardless of where the package is installed.

import os
from package.tests import __file__ as test_directory
 
def _data_dir():
    return os.path.join(os.path.dirname(test_directory), 'data')
 
def test_sample_data():
    file_path = os.path.join(_data_dir(), 'data.txt')
    with open(file_path) as f:
        package.module.do_something(f)

There you have it!

Lo and behold, there’s a way out! There’s very few valid excuses for not writing cleaner, prettier, more maintainable Javascript. Many of the same principles preached in Python hold true.

There are some prevalent concepts that can help us write better code. Understanding and applying unobtrusive Javascript can help alleviate everything from cluttered namespaces to browser differences and performance issues — I suggest reading the 7 rules. Following directly from that, progressive enhancement principles are fantastic to allow for graceful degradation and accessibility. Do with Javascript what we know we should do with CSS. Here’s some food for thought about progressive enhancement. Additionally, writing loosely coupled code (i.e. methods not tied directly to the DOM unless necessary) provides a separation of concerns that helps with debugging and testability. Finally, automating the testing of your code to ensure it’s doing what you think it should do (prior to sending it to QA for them to check) is powerful in and of itself.

If you’ve been bitten by the testing bug and find yourself wanting to test your Javascript code, you’ve come to the right place. The first question you should ask yourself is, “what should I be testing?”. I will focus on unit testing in this article. You should also be aware that there are powerful tools (e.g. Selenium) for integration and browser testing. But first things first.

So, what are common things done in Javascript that might need to be unit-tested? Here are a few examples:

• Client-side validation. Let’s ensure all bases are covered with validators that are written to check email addresses, birthdays, maximum lengths, etc.
• Methods that compute window sizes or element positions. There’s often lots of math, and edge cases can be killer.
• Basic things ingrained in the Dojo framework, such as class inheritance. You’ll want to ensure that your class behaves as you expect.

Let’s take the example of a email address validator and see how we might write it and test it. Here’s one method, which happens to validate a string expected to be a valid email address, with a length less than the specified maximum. This would be located at $JS/dojo1.2/src/app/validators.js.

dojo.provide('app.validators');
app.validators.isValidEmail = function(email, maxLength) {
    if (email.length > maxLength) return false;
    var pattern = /^([a-zA-Z0-9_\.\-])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})+$/;
    return pattern.test(email);
}

There are several things we might want to test. For example, we should test that the maximum length functionality works. Additionally, we should test that it doesn’t allow emails without a domain to pass through. And we don’t want to leave out testing that a valid email can pass through. In an ideal world, we would test every reasonable branch through the function, and through the regular expression itself.

Here are 3 test cases, presented in a format acceptable for the D.O.H. framework

Case 1: Too long of an email is invalid

runTest: function(){
    doh.assertFalse(app.validators.isValidEmail('123456', 5));
}

Case 2: Email without a domain is invalid

runTest: function(){
    doh.assertFalse(app.validators.isValidEmail('foo@.', 50));
}

Case 3: A valid email should validate as such

runTest: function(){
    doh.assertTrue(app.validators.isValidEmail('foo@bar.baz', 50));
}

We can then insert these into a D.O.H.-compatible test package. Open an editor to $JS/dojo1.2/src/app/tests/test_validation.js, and register the tests from above as shown below.

dojo.require('app.validators');
 
doh.register("app.tests.test_validation", [
    {
        name: 'test_validate_email_too_long',
        runTest: function(){
            doh.assertFalse(app.validators.isValidEmail('123456', 5));
        }
    },
    {
        name: 'test_validate_email_nodomain',
        runTest: function(){
            doh.assertFalse(app.validators.isValidEmail('foo@.', 50));
        }
    },
    {
        name: 'test_validate_email_ok',
        runTest: function(){
            doh.assertTrue(app.validators.isValidEmail('foo@bar.baz', 50));
        }
    },
]);

The last steps are to plug it into a test “module” (so it can be discovered by the D.O.H. runner), and run it to ensure things are working as desired. Point an editor to $JS/dojo1.2/src/app/tests/module.js, and add the following line:

dojo.require("app.tests.test_validation");

D.O.H. provides a browser-based test runner for executing tests. Assuming you have Dojo 1.2 available on your server, modify the following path to suite your installation: http://servername/js/dojo1.2/src/util/doh/runner.html?testModule=app.tests.module.

Hold tight for the next installment, which will include mocking in Javascript and introduce the Rhino runner. Happy coding!

• Port MockMe to the Dojo javascript framework
• Utilize browser history sniffing to build a generalized user segmentation framework
• Write a Ubiquity plugin for spreeder (to easily speed read a page in Firefox)
• Port OWASP’s AntiSamy project to Python, to provide comprehensive XSS protection

None of these are terribly difficult to get started, and with the summer winding down, I might have a few minutes of free time to start working on some.