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."

Comments

Unit Testing In The Schools...

[__aaclcg7560]

Why does it seem like unit testing is only taught in Java programming courses? I have never seen this in any C/C++, C# or Visual Basic courses.

Re:Unit Testing In The Schools...

[j-tull]

Unit testing, in my limited experience, isn't really taught in any programming course. Testing methodologies are typically taught in software engineering courses.

My software engineering course was fairly language independent (though most students used C++ since that was the primary language taught at this particular institution). Testing, in general, is a language independent craft.

I guess what I'm saying is that I disagree with your premise of unit testing only being taught in Java courses. I would guess that it's typically (but not always) taught in the same language as the given institution's introductory/intermediate programming classes.

Re:Unit Testing In The Schools...

[TrappedByMyself]

Why does it seem like unit testing is only taught in Java programming courses? I have never seen this in any C/C++, C# or Visual Basic courses.

Blame it on JUnit. Since it provides a way to make unit testing easier, it's easier to get people to actually do it. When I was in school, we talked about unit testing, but never really did it very well. By employing the latest buzzwords such as JUnit and Spring in your design, it's much less work to build your unit tests that it would be with other languages.

I also think, for better or worse, the the Java community is much more open to the latest toys than users of the other established languages are, which may explain why the XUnit variants in other languages haven't taken off as well.

Re:Unit Testing In The Schools...

[tcopeland]

Dr Stephen Edwards teaches about this in his classes. He's written an interesting paper "Using Software Testing to Move Students from Trial-and-Error to Reflection-In-Action" about his experiences with test driven design at VA Tech. You can see his home page here and that paper is the third one in the list.

I've recently been working on a BlueJ extension for PMD and he's quite active on the bluej-discuss list.

hmph

[Dominatus]

My unit requires no futher testing, thank you very much!

Less time for proper testing

[Barkley44]

As important as testing is, many clients (at least the ones I've dealt with) are willing to place testing on the back burner in turn for more output for the same amount of money. If code works right 95% of the time on the first try, that is a sacrifice they are willing to make. Obviously the more critical the product, the more testing is required.

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: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. 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.

Ironic

[snevig]

There's a javascript error in the article. Line 8, Char 76: Unterminated string constant

For .Net Developers...

[jferris]

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

http://www.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
http://www.codeproject.com/csharp/autp2.asp
http://www.codeproject.com/csharp/autp3.asp
http://www.codeproject.com/csharp/autp4.asp

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. ;-)

Aspect-oriented?

[jshaped]

ok, I'll take the hit and be the first.

wtf is Aspect-oriented programming?
how does it relate to object-oriented programming?

Re:Aspect-oriented?

[Trevahaha]

From Wikipedia:

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:Aspect-oriented?

[Peter La Casse]

The basic idea behind aspect-oriented programming is that you write code that will execute whenever a certain part of your program is reached. The most common example I've seen is that of a debug message that prints when every function is called; you could write the debug message in a separate function or file, and then via aspect-oriented programming not include code to call it in every single function. Instead you'd define an aspect, or something, and have your debug message print whenever the situation that defines that aspect occurs.

The promise of this is that you can save some effort by reducing repetitive function calls. The risk is that control flow can be very difficult to trace. Some people argue that aspect-oriented programming is similar to programming with goto, and I'm inclined to agree with them. It's useful under certain tightly defined circumstances and harmful otherwise.

Re:Aspect-oriented?

[archevis]

>> wtf is Aspect-oriented programming?

Aspect Oriented Programming is actually just a remake of the old comefrom pun. However, AOP is not a pun. It's a real life atrocity that should have been slain at birth. It can be visualized as having a piece of code "steal" the instruction pointer from somewhere inside another piece of code. And some morons seem to think that this constitutes good software engineering...

No, I'm not shitting you here, it's actually true! It just sounds like a joke.

And for the record: No, I don't hate Java. Quite on the contrary, I love Java. Furthermore, I am a heavily certified and devoted Java-only developer, and have been for 7 years. But AOP is a big-time fuck-up.

>> how does it relate to object-oriented programming?

It doesn't. Then again, most developers don't even know exactly what OOP really is, and what conceptually separates it from other paradigms. Hell, most "developers" don't even know what a programming language paradigm is.

So it all boils down to the buzzword factor.

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:Aspect-oriented?

[rbodkin]

First off, it's quite ridiculous to claim that an open source technology with no marketing behind it is somehow a "buzzword." AOP is gaining interest because of the success of those who are using it. When I was with the AspectJ team at Xerox PARC we did a workshop with IBM and they decided to invest significantly in the technology for internal use (not for marketing). AspectJ is now shipping inside WebSphere.

Aspects are great because the provide a useful means to abstract the relationships for policies, so we can finally cleanly capture hard problems like performance monitoring, consistent error handling, enforcing data security, or allowing product line variability for changing features in an application. This last one is the strategic reason for IBM investing: they can open source components but still integrate with different runtimes.

Obviously you've considered this really carefully. I can just imagine your intellectual predecessors sitting there 25 years ago fuming about how polymorphism makes it impossible to tell where a call in the program goes. "Leave my line numbers ALONE"

Aspects are great because the fact is that traditional OO just doesn't do a good job of modularizing (look it up) these hard but important problems. Of course, you also should consider the real world consequences of this problem (code gen, overweening frameworks, fragile code, etc.) Aspects promote good maintainable software for the real world. Just as was the case with OO, this new level of indirection requires some learning and good tools support.

Related Reference

[under_score]

I've written up a brief introduction to the qualities of an ideal test. 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.)

Edsger Wybe Dijkstra's qoute

[Device666]

"Program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence."Quote - Edsger Wybe Dijkstra. I get the "jibbies" in knowing that code is tested but not proven correct by design (program derivation).

Re:Programmer testing?

[adrianmonk]

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

From the context, it seemed pretty obvious to me that "programmer testing" means testing that is performed by programmers, as opposed to by a separate part of the development team that specializes in testing.

Having the programmer do some of the testing of his/her own code makes sense to me for several reasons:

1. Coverage. The programmer has a more intimate knowledge of the code and thus has better insight into ways it can fail than people who are looking at the code as a black box, which is basically what testers do. For example, if the programmer knows the code uses his own implementation of a hash, he knows to think about adding a test where the input data has two strings that have the same hash value to see if it properly handles collisions.
2. Testing efficiency. Because the programmer knows what the code is supposed to do, what the contracts are between classes and their clients, etc., etc., it's easier for the programmer to construct certain tests than for another person to learn these things and then create the tests. (Although on the other hand, the second pair of eyes might find things that the programmer didn't think of.)
3. Development cycle efficiency. If a programmer does the tests as he's developing things, he will discover bugs much sooner than if someone else is doing them. Perhaps days sooner. In general, the sooner bugs are discovered, the better, for several reasons. One is that code is easier to fix when it's still fresh in your mind. Another is that bugs may indicate a design flaw that will need to be corrected and may affect interfaces and thus require changes to client code (which may be written by other developers), and that creates overhead. Also, it means development versions of the software will be more stable and easier to work with (fewer crash scenarios to avoid when demoing to the boss, checking out if it's as usable as you thought, etc.)
4. Tracking overhead. If the programmer fixes bugs while still in the process of developing things, then he is the only one who has to know about the bug. Which means it doesn't have to go into a bug database, nobody has to spend 5 minutes discussing it in a meeting, etc.
5. Finding the source. If the programmer does the testing, it's much easier to trace that back to the source of the problem than if the tester just notices that the software fails in a certain scenario. It takes work to go from a scenario to the point where you know whose code fails (and thus who should fix it).

I'm sure there are other reasons, but the point is this: in many cases, increasing the amount of testing that the programmer can do is advantageous. (At least up to a point -- you need a second pair of eyes, and you need someone who tests how all the modules interact to see if the system as a whole works as expected.) But still, finding ways to make it possible and to make it easy for programmers to add more tests and better tests is usually a good thing.