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

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: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 [vt.edu] and that paper is the third one in the list.

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

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?

[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:Less time for proper testing

[Q2Serpent]

A good idea to get you started would be to write testcases for the problems you debug and solve manually. This has a few benefits:

- You are now familiar with the functionality of that piece of code, so writing a test should be easy.

- Having a test ensures that no future code changes will cause the same bug (it is very embarassing to re-introduce a fixed bug).

- Having a test also ensures that other code changes don't affect anything related to this functionality working. This can also help uncover unnecessary coupling - when this testcase fails in the future because something seemingly unrelated changed, you can investigate what is really going on because you will be alerted to it much sooner.

Re:Is this statement a joke?

[mcrbids]

Software Engineering is making leaps and bounds, so there are many tools available for writing good software. The people who really know what they are doing have more at their disposal. However, more than ever, there are a very large number of incompetent developers out there. It's much easier to get into programming now than it was in the machine language/assembly/C days because things are much easier to use, and the tools are much more accessible. Combine that with the .com influx of bozos and you have alot of people spewing out crap code.

Reminds me of a study done on Taxi cabs in San Fransisco shortly after ABS (Antilock Braking Systems) came out. As expected, the accident rate for those with ABS was quite a bit lower than those without ABS. But the surprise was that the death toll was about the same either way!

Seems that those with ABS tended to offset the benefits of ABS simply by driving harder, pushing themselves closer to the line for safety as a result of the certainty that they achieved with ABS.

In other words, people tend to identify "acceptable risk" and when the level of risk reduces, people then engage in riskier behavior in order to gain an advantage. This is not a bad thing - utilizing an advantage is an important part of survival in a "survival of the fittest" universe.

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:Edsger Wybe Dijkstra's qoute

[msbsod]

Edsger Wybe Dijkstra truly understood the virtue of the Lambda Calculus [wikipedia.org]. IBM software developers who advocate aspect-oriented Java code obviously still do not understand the concept, as the examples on the cited IBM Java web page show (see use of private variables).

There is a suprise in Aspect-J

[metalotus]

Having tried Aspect-J in a production environment, I found an unhappy surprise.

When you move beyond the trivial examples, you will encounter Aspect-J's long-standing bugs that simply crash your IDE every five minutes. For example, this P1 critical bug makes Aspect-J unbearable:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=4421 5 [eclipse.org]

I've heard of JBoss AOP being used successfully in production (http://www.jboss.org/products/aop [jboss.org]).