Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Unit Test Your Aspects 130

Posted by ScuttleMonkey from the sounds-like-a-dirty-joke dept.
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."
This discussion has been archived. No new comments can be posted.

Unit Test Your Aspects More

Unit Test Your Aspects

Comments Filter:

  • Unit Testing In The Schools... (Score:4, Insightful)

    by __aaclcg7560 ( 824291 ) on Monday November 14, 2005 @04:35PM (#14029551)
    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.
    • 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 gues
      • 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.
      • Unit testing, in my limited experience, isn't really taught in any programming course. Testing methodologies are typically taught in software engineering courses.

        I been taking courses at the local community college for the last five years on a part-time basis. Java is the only language course where the instructors stress that the input/output of functions should be tested/validated when designing the program. The other instructors either don't care much for the language they are teaching to emphasize thi
        • As the GP pointed out, unit testing has nothing to do with language, it is taught in software engineering. All language classes that I have attended (and taught) focus on the language itself. Teaching a programming language is similar to teaching algebra. It is not the correctness of the numerical answer that matters, it is how the student "worked out" the answer.

          I have also worked as a developer and system tester for over 15 years, primarily in C/C++, every single employer has demanded documented unit t
      • Every computer science class involving programming that I've taken (at the University of Toronto) involves unit testing, regardless of the language used.

    • Re:Unit Testing In The Schools... (Score:5, Insightful)

      by TrappedByMyself ( 861094 ) on Monday November 14, 2005 @04:48PM (#14029665)
      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.
      • Blame it on JUnit. Since it provides a way to make unit testing easier, it's easier to get people to actually do it.

        DUnit does exactly the same for Delphi, we are using it at my workplace together with a somewhat more advanced automated testing framework built around it. Works very nicely I have to admit, setting up test cases and collections takes only a few minutes for a new class. Throw in a test-driven XP development model and the result is a very dynamic and flexible development cycle, yet with a very
      • 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.

        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
      • Blame it on JUnit. Since it provides a way to make unit testing easier, it's easier to get people to actually do it.

        Don't forget NUnit [nunit.org], which allows JUnit-style unit tests to be constructed for .NET applications. I have no idea how many .NET developers actually use it, though.

        • If it helps with your numbers, my company uses it (along with NMock [nmock.org] — whose site appears to be down, ironically because of a problem with Java — for isolation) for all .NET projects.

          I love how they've used attributes in the implementation, makes things very easy. The Java (1.)5.0 implementation of JUnit uses this approach too, I believe.

        • My team is using it in a software engineering class project at Cal. It's incredibly straightforward and well put together.
      • Actually, take a look at TestNG [testng.org] if you want to get a sense of where testing in Java is headed (and I mean testing, not just "unit testing", which is just a subset).

      • It's not JUnit, it is because Java has garbage collection. JUnit is actually very easy to do in C++; after all, JUnit is a bunch of base classes that are extended and instantiated.

        Writing a test for an algorithm takes x4 the effort for the algorithm itself. Having garbage collection on board makes writing the test much easier than when not having garbage collection.

        The mental effort required to write code with manual memory management is tremendous. Imagine this effort quadrupled for writing the test, and y
        • > ...it is because Java has garbage collection...

          That's a really interesting point. My first reaction to the question was to say that Java lets you write code faster, not so much re-inventing the wheel; that the richness of available library functions allows the test writer that much more speed and flexibility. But I think you've actually hit on the real reason that test frameworks for C++ are so difficult, and so unreliable. Since most of the bad (that is non-obvious) C++ bugs tend to be memory rel

    • Unit testing is also big in Ruby on Rails (no "courses" for that though). I think it is a matter of whether or not there is a proper framework for implenting tests. If there isn't a framework, I can imagine unit testing becoming more work to implement than it is worth.

      -matthew
    • Apple's built some nice Objective-C unit testing functionality into recent versions of Xcode.
    • I don't know anything about the teaching side, but the JUnit framework has an equivalent C++ version, known as CppUnit. See http://cppunit.sourceforge.net/cppunit-wiki/FrontP age [sourceforge.net] for details. NUnit has also been noted elsewhere as a .NET alternative.
    • 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.
    • I've done unit testing in Delphiu (DUnit) and C# (NUnit). Unit testing is not a language thing, it's a good idea across the board.

      The schools will catch up soon enough.
    • >> http://frayspace.com/toomuchtv/isntthatgood/merryf unday.html

      Simple reason:

      C/C++ programmers: It works, dammit! We don't need no stinkin' testing.

      C# programmers: The compiler would warn or fail if it didn't work; if anything goes wrong in production, we'll patch it in the next release.

      Visual Basic programmers: Uh... testing? wuzzat?

                -dZ.
  • 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.
    • The quality of software has been continually declining for the last decade, I think.

      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 too
      • "Software Engineering is making leaps and bounds"
        "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.
      • 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 al
    • The widespread adoption of programmer testing over the past five years..."

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

    • so...win 95 was more stable then win XP?
      Gnome 0.1 (98 ish) was more stable then 2.12?
      Web pages worked better in Netscape 1.2 then they do in Firefox 1.1?

      The Standard File sytem back then was like Fat32. dude NTFS, ext3, RieserFS are all much better then what was avalible.

      I think you really need to go back an look at the Apps you were using in 95 dude.
      before, posting flame bait like this.

      p.s. you sir are a WANKER!

  • hmph (Score:4, Funny)

    by Dominatus ( 796241 ) on Monday November 14, 2005 @04:43PM (#14029622)
    My unit requires no futher testing, thank you very much!

  • I unit test all the programmers I hire... (Score:2, Funny)

    by Anonymous Coward
    ...but discard most of them due to faulty design.

      I do inquire if they have any siblings that may be been properly engineered.

  • Programmer testing? (Score:2, Informative)

    by richmaine ( 128733 )
    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 mor

    • Re:Programmer testing? (Score:5, Interesting)

      by adrianmonk ( 890071 ) on Monday November 14, 2005 @06:59PM (#14030677)
      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.

    • Clearly and accurately documenting what the program is supposed to do is a huge first step.

      Agreed, but I find that a lot of the time, particularly when working on projects where the requirements can change, unit testing provides a kind of documentation in itself. Even if the programmer has been too lazy to update the documentation for a method, the test itself must have been updated, so the functionality — provided that the tests have sufficient coverage — is described in the expectations of

    • English: The "other" code.
    • I have to take issue with this.

      A clearly written and exhaustive SPECIFICATION is the best and only thing required for a successful program. Documentation, architecture, user manuals, and testing all derive directly from the SPECIFICATION.

      Really, it works. Focus your effort on hammering out the speciification and you'll be amazed how easy the rest of the job is.

      As for JUnit: I've never tried it, is it fattening?

  • Less time for proper testing (Score:5, Interesting)

    by Barkley44 ( 919010 ) on Monday November 14, 2005 @04:46PM (#14029652) Homepage
    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.
    • 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.

      Yeah, but what is proper testing? Nowadays, really good testing needs to be an ongoing part of the development process. Everything the client sees, even the fir
      • Oh I agree - I'm refering to documented, structered testing by a third party. Even though developers can test it, it is more effective to get someone not in the development process to do the testing. You know, that one case you never thought about, no way a user would do XYZ ;) These are the cases where clients are willing to pass on since the budget doesn't allow for it. If they have $1000 to spend, they want as much physical code as possible. Spend $900 on dev, $100 on testing (as in work is done, test
      • 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...?
    • I agree. I currently working as a developer for a very large corporation, programming and maintaining life insurance applications, but I don't really "know the business" very well. I receive specs from the clients on what they want and we do our software design based on their specs. The clients review the software designs (called BSD's where I work), but sometimes I don't think they really pay attention to what they are reading.

      Since I don't have a life-time of experience working with insurance (only the
    • Testing, in this case, is a little different than what you are referring to. I dunno about AspectJ, but with Ruby on Rails you basically program in a bunch of use cases and mock data manipulations and run it with a "make" file. Any time you make significant (or not so significant) changes to the code, you can run your tests and make sure it all works.

      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 tes
      • 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 unnecessar

      • 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 t

    • I'm in healthcare IT, and needless to say, we test the daylights out of our code.
    • 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
    • My (personal) experience is that doing testing while development is ongoing adds ~10-20% more time (not including find-fix for either tested or non-tested dev. methodologies).

      When you add a find-fix cycle to either one (ie: prior to shipping to a customer), times can increase quite dramatically.

      I would further state (in my experience) that find-fix cycles on code that does not have automated, repeatable tests (be they integration or unit) ... the find fix cycles are larger and can cause more "trauma" if yo

  • Ironic (Score:5, Funny)

    by snevig ( 555801 ) on Monday November 14, 2005 @04:48PM (#14029664)
    There's a javascript error in the article. Line 8, Char 76: Unterminated string constant
  • 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

  • For .Net Developers... (Score:4, Informative)

    by jferris ( 908786 ) on Monday November 14, 2005 @05:10PM (#14029829) Homepage
    ..take a look at NUnit, if you haven't already:

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

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

    • This is slightly offtopic, but does anyone know of a site similar to codeproject.com that's less Windows specific or more Linux specific? Code Project has a lot of useful code and interesting articles, but even the OpenGL and Java Programming sections are mostly Windows specific, so they're less useful than they could be. So far the closest I've found is Artima.com.

  • Aspect-oriented? (Score:3, Interesting)

    by jshaped ( 899227 ) on Monday November 14, 2005 @05:13PM (#14029853)
    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? (Score:5, Informative)

      by Trevahaha ( 874501 ) on Monday November 14, 2005 @05:34PM (#14030007)
      From Wikipedia: [wikipedia.org]

      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? (Score:5, Informative)

        by ajs ( 35943 ) <ajs.ajs@com> on Monday November 14, 2005 @06:49PM (#14030593) Homepage Journal
        "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.

        • 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 instrument

    • Re:Aspect-oriented? (Score:5, Interesting)

      by Peter La Casse ( 3992 ) on Monday November 14, 2005 @05:40PM (#14030057)
      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.

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

        Is that like intercals "COME FROM" construct.

    • Re:Aspect-oriented? (Score:2, Insightful)

      by Anonymous Coward
      aspect-oriented programming is a sure way to write spaghetti code.

      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

    • Here's a better question for the AOP crowd: Can you *possibly* come up with a new example usagage? Since its introduction, AOP snake-oil types have been dragging out the now-threadbare "logging" example (see the other replies to the parent). Are there any more uses for this thing?
      • Sure.

        Mixins are a good example of AOP doing something powerful. AOP is a particularly good way of augmenting the functionality of objects without actually having to make those objects aware of that functionality by explicitly inheriting an interface.

        You can find a good example using a Lockable interface -- to make an y object temporarily immutable -- in the Spring reference documentation. [springframework.org]

      • Feature variation, usage metering, Error handling, error isolation, performance monitoring, account suspension, role-based and data-driven security, transaction management, failure injection for integration tests, performance monitoring, dirty tracking, relationship integrity management, architectural enforcement, raising business events, caching, prefetching ... Need I go on?
      • In our current java project we are using AOP to a certain degree, and I love it.. AOP comes in two flavours: - Introductions - add interface and implementation to your existing classes (kind of support multiple inheritance, as java doesn't) - Advice - add functionality before, after, around your exisiting code. Your existing code in this example may be a method call, a static block executing, a read or write of a class variable. In our projects we are only using advices on methods. We have developed a sy

    • Re:Aspect-oriented? (Score:4, Insightful)

      by archevis ( 634851 ) on Monday November 14, 2005 @06:13PM (#14030313)
      >> wtf is Aspect-oriented programming?

      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.

      • Re:Aspect-oriented? (Score:5, Insightful)

        by rbodkin ( 931093 ) on Monday November 14, 2005 @09:31PM (#14031589)
        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.

      • Re:Aspect-oriented? (Score:2, Insightful)

        by kavi_3 ( 5872 )
        I have to say, I can tell you've never seen a good example of AOP in action. It's a very powerful tool for certain kinds of problems. Crosscutting concerns is not just a buzzword. There are certain requirments in many software projects that cut accross many modules and sections; examples being security, transactionality, policy enforcement, the list goes on and one. One example is any problem that could be solved with the Visitor pattern can be solved with aspects in way that is far simpler and maintain

      • And some morons seem to think that this constitutes good software engineering...

        The "moron" in question here is Nicholas Lesiecki, author of Java Tools for Extreme Programming: Mastering Open Source Tools Including Ant, JUnit, and Cactus [amazon.com]. This review [ercb.com] in Dr. Dobb's Journal calls it "original and useful".

        He is also a contributor to Cactus [apache.org], "a simple test framework for unit testing server-side java code", part of the Apache Jakarta project.

        He is currently a software engineer and programming instructor wit

    • Re:Aspect-oriented? (Score:3, Informative)

      by ggwood ( 70369 )
      There is an attempt at a jargon-free explanation here [jroller.com].

    • So far as I understand it, AOP is a way of implementing a kind of "policy" that is shared at different levels or classes in your code.

      One of the major applications that convinced IBM into AOP was to implement a new logging technique into a big system. Obviously it would take thousands of man hours if you went and did it manually (even if it was outsourced to India!). With AOP IBM realized that they can define the cut-crossing concern, for example, at the end of all methods that communicated to an IO devic

  • Related Reference (Score:5, Informative)

    by under_score ( 65824 ) <mishkin.berteig@com> on Monday November 14, 2005 @05:21PM (#14029900) Homepage
    I've written up a brief introduction to the qualities of an ideal test [agileadvice.com]. 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.)
  • Using automated unit test frameworks such as JUnit [junit.org] 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 [agileadvice.com], and the underlying principles [agileaxioms.com] and practices of Agile. The situations where it can apply best have some sort of technological support for automa
  • 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 [wikipedia.org] based concepts.
    • 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
      • Absolutely, one can write reliable code in Fortran, too. Excellent supporting tools like SCA (Source Code Analyzer) and DTM ( DEC [digital.com] 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

  • Edsger Wybe Dijkstra's qoute (Score:3, Insightful)

    by Device666 ( 901563 ) on Monday November 14, 2005 @06:43PM (#14030554)
    "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).
    • 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).
      • I'm not sure I understand. What's the problem with using private variables?
      • Yes. It is so strange the software industry has problems with delivering quality. Ofcourse code should be as faultless as possible. And ofcourse that means programmers should be educated enough to feel responsible and use some form of formal verification. If it's so poor understood even at the bigger companies, it shows that if anyone who can construct some if-else-construction is easily considered a programmer. I had a little bit of programming education when I did my study of interaction design at an at a
  • 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 requ
  • 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.
    • aspects have a lot in common with decorators, IMO.

      i guess the author (i didn't read it of course) wanted to use something a bit more colorful than the typical logging example. there's many many places where aspects make sense, and most of those places have to do with extracting the layers of cruft we've added to our software layers. most of that cruft serves a usefull purpose, but gets in the way of application logic (security, logging, transactions, framework baggage).
  • I can't really see the light until I find the perl version of it. I guess I've been spending too much time in perl land. I had to look at Catalyist to figure out RoR. Heh.

    But perl has Test::Class [cpan.org] 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.

  • The widespread adoption of programmer testing over the past five years

    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 ?)

  • 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]).
  • 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.
    • Are there any lisp libraries/packages for logging, which will log the function name and probably the line number, etc.

      So far I have been logging in lisp only using a homewritten trivial 'tracer' macro.
  • 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 u

  • Worked with AOP (Score:3, Insightful)

    by El_Muerte_TDS ( 592157 ) on Tuesday November 15, 2005 @02:53AM (#14032951) Homepage
    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.
  • [As Minna Kirai said]

    And since Aspect-Oriented programming is a patented technique http://www.pmg.lcs.mit.edu/~chandra/publications/a op.html [mit.edu] , basically you can not use it.

    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=PT 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,0 [uspto.gov]

Slashdot Top Deals

In practice, failures in system development, like unemployment in Russia, happens a lot despite official propaganda to the contrary. -- Paul Licker

Close