Slashdot Mirror
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."
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.
The widespread adoption of programmer testing over the past five years has been driven by the demonstrable productivity and quality of the resulting code
The quality of software has been continually declining for the last decade, I think. If anything, we're just better at teaching users to avoid things that don't work.
This is my sig.
My unit requires no futher testing, thank you very much!
...but discard most of them due to faulty design.
I do inquire if they have any siblings that may be been properly engineered.
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.
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.
KeepTrackOfIt.com - Find the lowest gas prices in your area graphically
There's a javascript error in the article. Line 8, Char 76: Unterminated string constant
I also liked this gem:
"This oft-overlooked distinction is crucial. Freedom is being able to make decisions that affect mainly you. Power is being able to make decisions that affect others more than you. If we confuse power with freedom, we will fail to uphold real freedom."
This leads us to a conundrum:
Information is power. Information wants to be free. Therefore, freedom is power. But according to GNU, freedom is not power.
Kidding aside, I don't really agree with GNU. I mean, if you license your software under the GPL are you not asserting your power over other developers to abide by that license? Whatever license you choose, others must follow it; so in terms of affecting more people or only yourself I fail to see the relevance of the license you choose. If you want real freedom, shouldn't you put your source in the public domain? Having no license makes the software available to everybody and restricts nobody. The only difference is that people are not forced to contribute back. And isn't forcing people to contribute back asserting power over them?
Now I will sit and wait for some "intellectual" to explain how I have confused things and am incapable of understanding and properly interpreting the GPL, which apparently is the only license that software developers should choose.
1. Find an article on a development-oriented site. Possible sites include: www.ibm.com/developerworks, www.macdevcenter.com, devx.com, and persiankitty.com.
2. Pick a recent article on your chosen site.
3. Paraphrase the article in a few sentences, or if thats too difficult, just cut and paste the first few sentences of the article.
4. Post your paraphrase/cut and paste, along with a link to the article, to slashdot.
5. Bask in the glory as people attribute your ability to find an article with actually knowing what the article is talking about.
Thank God for the 2000 tech crash! Any programmer who doesn't do some amount of their own testing is a moron. I think the lack of testing is a leftover from the time when English majors were getting dev jobs at dot-coms...
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. ;-)
You are in a maze of little twisting passages, all different.
ok, I'll take the hit and be the first.
wtf is Aspect-oriented programming?
how does it relate to object-oriented programming?
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.)
Helping with organizational effectiveness is our job.
...does not deliver. It turns out that there aren't that many cross cutting concerns in any most applications. Even when there are a number, aspect composition makes code difficult to understand. Aspects also make code much harder to understand.
Chalk it up as yet another failed silver bullet.
Using automated unit test frameworks such as JUnit is one of the most important engineering practices in the whole suite of agile practices. Many agile practices that don't explicitly ask for test-driven development still will insist that Agile is enabled by technology that allows for fluid, testable work. I'm very interested in Agile applied outside of software, and the underlying principles and practices of Agile. The situations where it can apply best have some sort of technological support for automation, and in particular automation of tests. I have seen situations where spending >$50,000.00 to build a custom automated test harness is money well spent in order to avoid mistakes in the first place. One of the main principles of Lean (a heavy source of influence for Agile), is that you can only go fast if you have exceptionally high quality. Any source of defects slows a project/team/production line down.
Helping with organizational effectiveness is our job.
The examples shown on the mentioned web site illustrate very nicely what is wrong with software development. First, iReallyHaveAHARDtimeToRead->thisStuff. Second, when will people give up Fortran programming, such as private variables, global variables or COMMON blocks? Testing is good, but it becomes a Sisyphus task with side-effects based concepts.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww -128.ibm.com%2Fdeveloperworks%2Fjava%2Flibrary%2Fj -aopwork11%2Findex.html%3Fca%3Ddgr-lnxw01AOPtestin g
Validator.w3.org reports 33 bugs.
"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).
What we need is G-Unit testing.
http://www.ggg-gmail.com/
Who's gonna step up to the plate?
We have a brand new buzzword^H^H^H^H^H^H^H^Htechnology that will save you millions and make all your technology function correctly. It's called AOP. It'll make your code more complex, probably force you to use non-standard implementations of Java, but it will be worth it in the end. We promise. Trust us.
Bring back the concept of RAPID application development. The only thing that was missing over 10 years ago was scalability. Today's frameworks are bloated and horrible. Testing will be much simpler, and require less tools when it's QUICK to build screens, and you don't have to propagate changes by hand to 15 layers of damn code. You may also need to employ a test team that has an understanding of how the code works, as well as the business requirements. It can and has been done.
These posts express my own personal views, not those of my employer
The author uses a text highlighter as an example of an aspect. I don't see how this is a cross-cutting feature. Why not just put that logic in a TextHighlighter class, and use it via a simple method call? Or use it in a Decorator pattern?
I got nothing against Aspects, but I just think they should be used when they make sense, like everything else I guess.
"In our tactical decisions, we are operating contrary to our strategic interest."
But perl has Test::Class which does a whole xUnit type thing inside the Test::Harness framework. Nice. However it also tells me on that page, not to bother with it unless I'm reduplicating the same code over and over in my tests -- which I usually do not.
I guess Test::Harness is plenty for average joes like me.
Imagine if you weren't allowed to use roads because a bus company complained about your driving 3 times. --skunkpussy
The flight ops system I worked on at a major airline only a few years ago is written in Fortran and runs in a mainframe transaction environment that gets rid of common problems like buffer overflows and that provides a nice event-driven environment in which users obtain or enter data on quick-hitting text screens.
For what it's used for, the general environment is very well tailored for the task, and the code in question tends to be a mix of simple text parsing and fairly complex computations, so a language like Fortran with a few specialized text parsing library routines turns out to be an excellent choice!
With appropriate coding standards (e.g., make all variables global, but equivalence them to a single integer array so one can easily initialize all variables in a given program at the top to avoid reentrancy errors) it isn't all that hard, but one *does* have to create and then FOLLOW a decent set of coding standards to make it work.
This is true of all languages, not just Fortran.
We had some pretty good automated testing/scripting facilities on the mainframe in the late 1980's when I first started coding professionally at Unisys, and it's a shame that more developers aren't made familiar with such tools. They can make regression testing a lot easier!
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Absolutely, one can write reliable code in Fortran, too. Excellent supporting tools like SCA (Source Code Analyzer) and DTM ( DEC Test Manager) have been around since a long time, not to mention the superb VAX/VMS Fortran compiler.
I just would not agree with you on the global variables and initialization. Complexity of data exchange via global variables beats every attempt to debug such code. Your initialization helps to avoid some mistakes, but the basic problem remains. Exchange of information through side-effects (global, private, doesn't matter) is always more complicated to understand than exchange of information through a list of input and output arguments at every function call.
People also tend to think that bad things happen because variables were not initialized. I have heard more than once from OOP advocates that constructors are important, because they allow the software developer to implement an automatic initialization of variables. The truth often is that worse things happen if they are initialized, typically with something like zero, than having a random value. Because, if they are initialized with zero, then chances are that your code runs through without any obvious problem, although the result may be worthless. And you may not notice it. I completely avoid global variables (or private variables in classes). For testing purposes I initialize local variables with NaN's instead (for floating point variables), which happen to be huge integer numbers, too. Of course I also rely on the compiler's ability to detect the use of variables which have not been assigned a value before, something that cannot work with global/private variables. But the compilers have their limitations. However, a dummy intialization, like the method you mentioned or a typical C++ constructor implementation, would completely defy the compiler's test for uninitialized variables (that is initialized with a correct value, not with something like a zero). In any case, my favorite ultimate test utility is a debugger. From my own past experience (almost 3 decades, more than a dozen languages) I find any whateveryounameit-oriented black box concept less useful for debugging (say "testing step-by-step").
One can make the same mistakes in Fortran, Java, C++ etc.. The more things change, the more they stay the same; as the mentioned example on IBM's "aspect-oriented code" Java web page shows.
OMG - you mean .. when I tested all that code I wrote between 1973 and 2000 I was doing something *different* from all you guys ?!
Why didn't someone tell me I was doing it wrong ?
(Seriously, WTF does that sentence even mean ?)
If you don't pray in my school, I won't think in your church.
Developers cannot let themselves be caught in that trap, so they need to test as they go.
Does the typical programmer code s significant chunk of programming before testing, or are there short spurts of code, then test, then code...?
Verbiage aside...
Aspects add behavior to OO programs, like new members and new code. The main benefit is being able to say in one place what you would say in many places - easier to write, test, and change.
AOP is well-accepted in many forms. AspectJ is in MySQL connector/J, WebSphere, etc. JBoss/AOP is in, well, JBoss, i.e., everywhere. Many OO techniques are AOP precursors, and some handle AOP applications happily. So if you don't need or want aspects, don't use (or promote) them.
To test common behavior throughout a program, try an aspect. To test an aspect that affects a lot of your program without having to write lots of tests, then read the article. If you're interested in how to write tests that affect a lot of your program, but don't want to use aspects, read the article anyway since the problems are the same.
Happy coding...
Having tried Aspect-J in a production environment, I found an unhappy surprise.
1 5
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=442
I've heard of JBoss AOP being used successfully in production (http://www.jboss.org/products/aop).
The only solid, persuasive cross-cutting concern in all AOP literature is logging (e.g. logging when a method is invoked and such). This would be properly solved by having an easy-to-use "tracing" infrastructure in the language, like Lisp has.
I really wish I could have caught this one sooner, unit testing is a great idea if you want a generic, vanilla way of testing a program or function, I'll grant it that, it is extremely useful, in a vanilla and pretty standard way. However, I'd really like to point out that there's no better form of debugging than sitting down with a few friends (or an associate of some kind, if this is in a work environment) and reading over the source, and you'll learn more from this method, also. I honestly think that unit testing has, in fact, taken over debugging as the battlefront aganst bugs in code, but no step should be left out, the program should be tested, debugged, and eventually evaluated by a group of other professionals, I just thinkt his step is essential.
I like suggestions, but I don't like contributing towards them.
Sounds like a good way to debug, might have to try it. Oh yeah and the title sounds dirty.
I worked with AOP a bit (AspectJ and Compose*) and I can tell you this. I have mixed feelings about the use of it. For example AOP is simply awesome if you want to add debug code to your whole application so you can easily add\remove call tracing\logging to find where the program craches (ofcourse you could do the same with in C\C++ with some macros, but it's a bit more work). On the other hand you will completely lose overview on how your AOP changes affect the program in a whole. Even with the visualisation tools that come with AspectJ is not easy.
And these are two different martial arts. Java is for Internet kids who have the luxury of running over an operating system (even MS-Windows included..), but real programmers, who have to squeeze into some 128K of flash memory an entire communication application on a lousy 16-bit DSP CPU with tight power consumption budget, will always do some dirty tricks no quiche-eaters unit-testing module will help. Startup idea anyone? A CPU that runs Java. JVM in hardware, that is.
[As Minna Kirai said]
a op.html , basically you can not use it.
T O1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm &r=1&f=G&l=50&s1=6,467,086.WKU.&OS=PN/6,467,086&RS =PN/6,467,086
T O1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm &r=1&f=G&l=50&s1=6,442,750.WKU.&OS=PN/6,442,750&RS =PN/6,442,750
And since Aspect-Oriented programming is a patented technique http://www.pmg.lcs.mit.edu/~chandra/publications/
So, who really cares if its theoretically any good, when legally it is worthless?
See US patents 6,467,086 and 6,442,750 :
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=P
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=P