Unit Test Your Aspects 130
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."
Unit Testing In The Schools... (Score:4, Insightful)
Re:Unit Testing In The Schools... (Score:3, Insightful)
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... (Score:5, Insightful)
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:Is this statement a joke? (Score:3, Insightful)
"However, more than ever, there are a very large number of incompetent developers out there."
Do you think that these statements are related in any way? I mean, using software evaluation / developmentation method X seems to be the equivilant of having a safety net. And there's definately a lot of developers out there that need one.
Re:Less time for proper testing (Score:2, Insightful)
Re:Less time for proper testing (Score:3, Insightful)
And if you really want to get serious about tests, there is technique where you program the tests BEFORE you implement the code. You just keep running the tests until they don't fail and you know you are done (well, almost). It is called test driven development. From that I understand, it saves a good deal of time that would otherwise be spent clicking through an application to see if it works.
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.
At this point, I think it is more an issue of discipline than man hours. If I could just get myself to spend a whole day getting tests written, I believe I would save myself far more than that in debugging and traditional testing. And I would feel much more confident about my finished product.
-matthew
Re:Aspect-oriented? (Score:2, Insightful)
What you do is you write a piece of code where part of it is a regular expression that matches one or more methods in your existing code, and another part is either the symbol "before", "after", or "both".
When you compile the code, the aspect's code is inserted before, after, or both before and after, the existing code. Your source isn't changed, just the binary.
So if every time the method Foo() is called you want it to call Bar() before and Baz() afterwards, this is a great way to do it.
The downside is, if you look at the source code at the place Foo() is called you will have NO IDEA that Bar() and Baz() are being called, because the code is inserted at compile time. If you debug the executable the call becomes obvious, but it's caused many a WTF on my part.
Lisp has had this sort of thing for years, with it's
Re:Unit Testing In The Schools... (Score:3, Insightful)
At this point I'd like to point out the existence of JML [iastate.edu], an annotation syntax and set of associated tools for Java that makes a lot of things easier and more convenient. JML allows you to do design by contract in Java and if you compile with the provided compiler jmlc it will automatically include runtime checks based on your pre and post conditions and invariants. Another tool, jmldoc, will generate JavaDoc documentation augmented with the extra specification your provided with JML annotations, making for much better documentation. You also have jmlunit which will automatically generate JUnit test classes based on your annotations.
That means you get automatically generated unit tests, the constraints of which are automatically included in your documentation (as well as in the actual code as annotations) and the option to use those constraints as runtime checks for debugging purposes. That's an awful lot of cheap benefits just for writing annotations to your code as you go.
General examples of using JML for DbC can be found here [iastate.edu], and examples of jmlunit generating JUnit test classes can be found here [iastate.edu].
Jedidiah.
Re:Aspect-oriented? (Score:4, Insightful)
Aspect Oriented Programming is actually just a remake of the old comefrom [wikipedia.org] 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.
Edsger Wybe Dijkstra's qoute (Score:3, Insightful)
Another methodology bandwagon (Score:2, Insightful)
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.
Re:Aspect-oriented? (Score:3, Insightful)
Sorry, my mod points just ran out, or you'd have been (+1, Insightful).
Speaking of moderation, the fact that a post quoting the phrase "modularization and encapsulation of cross-cutting concerns" was modded (+1, Informative) is itself (+1, Funny). :-)
Maybe it's just me, but I've never appreciated what's supposed to be so great about aspects. Yes, it might be useful to be able to introduce some debugging diagnostics at the start and end of every function automatically. We use a pretty powerful instrumentation system in our code at work, but having to stick a macro at the start of every function to make it work is tedious (though hardly the end of the world).
But what else is it good for? I've looked into AOP a couple of times now out of curiosity, made the effort to read some of the background papers, and now placed it firmly on the level of so-called extreme programming: much hype, toy examples, few to zero real world case studies showing measurable benefits. I haven't read every single post in this discussion yet, but probably the majority, and I've yet to see anything other than the same old example (or thinly disguised variants of it) repeated ad nauseam. Maybe one of the AOP advocates can tell me what I'm missing?
Re:Aspect-oriented? (Score:5, Insightful)
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.
Re:Aspect-oriented? (Score:2, Insightful)
I work on a very large software project that uses aspect in several different ways. On example is for transaction management. We have an aspect that is able to start a transaction at any method marked with a @Transactional annotation. And you can create aspects that do things like inject a caching system objects in a way that doesn't force the object to be aware that it is being cached. Catch business events that should happen at certain times without littering your code with calls to raising that event. It an extremly powerful tool.
The problems with aspects are the lack of tool support. It can slow down compiles and mess with debuggers at times (I know, I've had to deal with this). However this will improve over time. Another improvement is runtime weaving, where the aspects are woven into the code at runtime. This allow you to run the aspects when you actually need them (production, integration testing) and not when you don't (unit testing).
And the compaint about not knowing where the flow of control is going is similar to the complaints about OO and ploymorphism. Yes, it can make it a little harder understand a program at first, but with the proper tools and some time, it will make the program far more maintainable.
You have to know when and where to use it.
Worked with AOP (Score:3, Insightful)
Software Patents Considered Harmful (Score:2, Insightful)
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