Unit Test Your Aspects

An anonymous reader writes "The widespread adoption of programmer testing over the past five years has been driven by the demonstrable productivity and quality of the resulting code. Find out why and how to do it, as this article introduces you to the benefits of testing aspect-oriented code and presents a catalog of patterns for testing crosscutting behavior in AspectJ."

Programmer testing?

[richmaine]

The widespread adoption of English over the past 5 years has been driven by the demonstrable productivity and quality of projects where it has been used to communicate instead of just to write meaningless words. :-)

Programmer testing? That means testing programmers, as in certifying them? Apparently not.

From the article, it is clear that they are referring more to testing of programs. Of course, then one might wonder who would think that nobody ever tested any programs prior to 5 years ago.

Reading a bit more carefully, it appears to really mean testing of programs using a particular testing paradigm.

I am quite serious in my observation that clearly written documentation is a huge benefit in getting programs to actually work. Clearly and accurately documenting what the program is supposed to do is a huge first step. For example, program documentation needs to be a whole lot more clearly written than the subject article.

For .Net Developers...

[jferris]

..take a look at NUnit, if you haven't already:

http://www.nunit.org/ [nunit.org]

Then, read Marc Clifton's series on Advanced Unit Testing in C#. The code is easily ported to VB.Net, as well, although not required. I am working on introducing the practices outlined in the article where I am currently employed.

http://www.codeproject.com/csharp/autp1.asp [codeproject.com]
http://www.codeproject.com/csharp/autp2.asp [codeproject.com]
http://www.codeproject.com/csharp/autp3.asp [codeproject.com]
http://www.codeproject.com/csharp/autp4.asp [codeproject.com]

As if CodeProject wasn't slow enough. The readthroughs on this post should bring it to its knees in no time at all. If you have a chance, look at some of Marc's other postings, as well. Very high quality stuff.

In regards to Unit Testing in general, I don't know why it isn't given more weight in college coursework. Honestly, it would make a great course, or series of courses. I've been out of school for just a wee bit though, so maybe some are offering it already. ;-)

Related Reference

[under_score]

I've written up a brief introduction to the qualities of an ideal test [agileadvice.com]. The great thing about unit test frameworks such as JUnit, NUnit, CPPUnit, etc. is that they manage to satisfy all of these qualities: Decisive, Valid, Complete, Repeatable, Isolated and Automated. (Although it is possible to break some of these qualities with poor test creation practices.)

Re:Aspect-oriented?

[Trevahaha]

From Wikipedia: [wikipedia.org]

In software engineering, the programming paradigm of aspect-oriented programming (AOP), also called aspect-oriented software development (AOSD), attempts to aid programmers in the separation of concerns, or the breaking down of a program into distinct parts that overlap in functionality as little as possible. In particular, AOP focuses on the modularization and encapsulation of cross-cutting concerns.

Re:Less time for proper testing

[dubl-u]

If code works right 95% of the time on the first try, that is a sacrifice they are willing to make.

That may be a possible choice with traditional QA testing (which you do right at the end), but that's not the notion with unit testing. I don't write tests to increase quality as such; I write them to increase my development speed. If the code usually works, I spend very little time debugging. When I do make mistakes, the test coverage means I generally find out right away about bugs, so the problems are easy to find. And when I'm doing new work, the existing suite reminds me of all the little details that went into the existing code base, meaning I have to spend a lot less time on design archeology before ading new features.

I don't do test-driven development just for better quality. I do it because it helps me go faster, and with less stress to boot.

Re:Aspect-oriented?

[ggwood]

There is an attempt at a jargon-free explanation here [jroller.com].

Re:Aspect-oriented?

[ajs]

"modularization and encapsulation of cross-cutting concerns."

And it's just that kind of buzzword-to-noise ratio that makes people ignore AOP.

In reality, AOP is a structured way for a programmer to modify existing classes an an OO system without sub-classing. So, here's AOP in Perl, just as an example:

package SomeClass;
...
sub somemethod {...}
...
# And then later in your code:
my $oldmethod = \&SomeClass::somemethod;
*SomeClass::somemethod = sub {
  print "Invoking somemethod...\n";
  goto $oldmethod;
}

I used Perl's stackless-invocation goto semantics here for two reasons: it's the most efficient way to do this; but it's also an eye-catcher that (because of the bad blood programmers tend to have with respect to C or BASIC style goto) highlights what I think the problem is.

I tend to try to avoid this kind of thing in my programs, regardless of language, except where I make it very clear that functionality can and should be added, in which case I provide a mechanism. So, I'm not sure how AOP could work well (it's supposed to be used in those cases where the original author didn't have any idea about what you want to do). Sub-classing or re-writing such code has always seemed the right way to go to me.

How, for example, are you supposed to maintain code where a substantial change to any library routine's internal behavior could cause catastrophy for someone who has tried to add behavior to it? I suppose you could lexically scope such constructs, which would be reasonable, but no... I think this is just an attempt to get a small portion of what smalltalk or ruby style mix-ins/traits would give you.

Then again, I guess the problem really stems from trying to use a high-level language (Java) which attempts to simulate the constraints of a low-level language (C or C++) while users attempt to use it as if it were high-level (like Smalltalk, Haskell, Python, Perl or Ruby).

In the end, it seems to make more sense to use Java the way it was intended to be used, and use high level languages where you want dynamic features like the ability to reach into someone else's code and do whatever you like.

Re:Less time for proper testing

[stg]

Personally, I haven't been able to get into it too deeply. Writing new tests from scratch in a project for which you've already written a big chunk code is daunting and tedious, IMO. You literally have to go step by step through the program and simulate every forseeable use case. I did write some tests and I can see the benefit. I tested what I thought was some rather simple code and found bugs right away. Bugs that might not have been obvious by simply clicking through the application. Also, writing such tests can give you ideas for features that you might not have thought of before.

A great book on the topic of adding tests to old code is Working Effectively with Legacy Code [amazon.com]. There are a lot of techniques there that I've found very helpful while refactoring projects done before I started using automated tests (in my case, using DUnit).

Writing tests really helps reducing excessive coupling in your code, too. If you need to use and initialize a lot of classes for a simple test, it's usually a sign that they are a bit too dependent.

Re:Unit Testing In The Schools...

[timcrews]

I don't know anything about the teaching side, but the JUnit framework has an equivalent C++ version, known as CppUnit. See http://cppunit.sourceforge.net/cppunit-wiki/FrontP age [sourceforge.net] for details. NUnit has also been noted elsewhere as a .NET alternative.

Re:Unit Testing In The Schools...

[JSR $FDED]

Actually, take a look at TestNG [testng.org] if you want to get a sense of where testing in Java is headed (and I mean testing, not just "unit testing", which is just a subset).

Re:Aspect-oriented?

[tootlemonde]

And some morons seem to think that this constitutes good software engineering...

The "moron" in question here is Nicholas Lesiecki, author of Java Tools for Extreme Programming: Mastering Open Source Tools Including Ant, JUnit, and Cactus [amazon.com]. This review [ercb.com] in Dr. Dobb's Journal calls it "original and useful".

He is also a contributor to Cactus [apache.org], "a simple test framework for unit testing server-side java code", part of the Apache Jakarta project.

He is currently a software engineer and programming instructor with Google.