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

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.

Ironic

[snevig]

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

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

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.