Using Aspects as a Test Coverage Tool


News: Using Aspects as a Test Coverage Tool

  1. Using Aspects as a Test Coverage Tool (8 messages)

    Sam Pullara is a busy guy at the moment. In this entry he discusses the use of AspectJ to give him a test code coverage tool. It allows you to query "What tests cover the foo*() methods" and the like.

    I was working on the Groovy project and I wanted to know what tests covered a method I was modifying. I tried to use clover to do this but it gave me way too much information and most of it wasn't that useful. Maybe AspectJ could help?

    We are using JUnit for Groovy so all tests happen to extend a particular base class and each test method has a particular naming convention.
    Read Using Aspects as a Test Coverage Tool

    Threaded Messages (8)

  2. Running the risk of showing my ignorance

    Could someone explain to me what exactly it is aspects provide that dynamicly typed languages like python haven't provided for ages?


    def logInterceptor(method):
        def f(*args):
            self = args[0]
            print "before"
            return apply(method, args)
        return f

    # introductions

    class Introduction1:
        def doSomething(self):
            print "i've done something"
    class Introduction2:

        def doSomethingElse(self):
            print "i've done something else"
    class SomeClass(Introduction1, Introduction2):
        "just some class"
    SomeClass.doSomething = logInterceptor(SomeClass.doSomething)

    def main():
        myClass = SomeClass()

    if __name__=='__main__':
  3. I am not very familier with the python syntax but it seems to me that all you have done is demonstrated one way of implementing an 'AOP-like' solution. The same could be done in Java using dynamic proxies or even the decorator pattern. This is not something exclusive to "dynamically typed languages like python".

    If I recall correctly, the spring framework does use dynamic proxies to provide AOP behaviour, an approach I personally prefer to bytecode manipulation (which I believe is the method used by aspectJ).

    AOP simply attempts to standardise on the terminology of these concepts given that cross-cutting concerns are something implemented in many different ways by many different developers (A noteable example being services provided by application servers to components such as EJBs).

    There is no real magic about it, and yes, I would expect that any OOP language worth its salt already has some kind of mechanism to perform 'decoupled pre and post functionality'.

    The justification for using tools such as aspectJ to do this work is the same as using tools such as struts instead of building a 'home-grown' MVC web framework.
  4. Value of AOP[ Go to top ]

    The value of AOP is modularity, being able to trace a particular requirement right down to the code, and to isolate that requirement in such a manner that it can easily be added/removed/changed without having to update a bunch of objects. Interceptors, introductions, mixins etc. are really nothing more than a means to an end.

    Where AOP has the most value today is in developmental tasks, such as testing, profiling, proof-of-concept, prototyping, because AOP allows you to easily swap out different alternative architectural approaches in order to evaluate the best solution. AspectJ is a tremendously powerful tool for implementing coding policies that can be catch coding standard violations at compile time, rather than having to rely on time-consuming, resource-draining code reviews.

    Ramnivas Laddad's book, "AspectJ In Action" covers these topics much more in-depth. I highly recommend it to anyone interested in learning about the value proposition AOP brings to the table.
  5. I was just wondering if there was more to it. If thats not the case it seems to me they just took something that is trivial to do in scripting languages, ported it to compiled languages slapped a label on it, and made a lot of noise about it
  6. Peter, I'm interested in knowing more about scripting languages already have this capability. I don't know python and know only a little about AOP and AspectJ, so please excuse my ignorance.

    Let say we have a dozen or so business classes and we wanted to add certain functionalities such as logging, caching and access rights, which was ignored initially. Now, in the phase to develop and incorporate those features, I will select a logging lib, say log4j, any caching lib and create my own access rights functionality. I then create 3 aspects for each one and create the necessary pointcuts to the dozen or so business classes. I don't need to touch any of these classes. I can add new aspects, change the aspects to use a different lib for logging/caching/access rights, remove any aspects from one or more of those classes, all without changing/touching the existing dozen or so business classes and rather easily.

    My question is, is it as easy to do this in a scripting language like python? I like the ease of adding/removing an aspect to a hundred or so classes almost effortlessly.
  7. It seems to me that with a few minor changes to his code sample above it would be possible to do exactly that...

    Firstly, the Interceptor code would need to 'pull' the method names from the managed class rather than have the passed to it, enabling the interceptor code to be totally decoupled.

    Secondly, some kind of pattern matching for method names would be required, so that many methods from many classes could be selected for the interceptor.

    Lastly, the selection of methods to 'manage' would need to be moved from code to configuration.

    It seems to me that if these relatively minor changes were made then you would have a simple AOP implementation. The methods that are managed by the interceptor would probably need to be grabbed and managed at startup, but during the rest of the runtime, I believe the net result is the same. However, being neither an expert in AOP or Python, im sure someone can prove me wrong.
  8. Wesley, if python support stuff like that, then it would be minor, else, it may be a major change :), IMHO.

    What about Introductions? Would that be needing python to 'add' codes to existing scripts or in some other way?

    And what about the runtime weaving capability, which does not require the source code and thus weaving can even be applied to 3rd party jars?

    Can python or any other dynamic scripting lang support this? It would be great if this is really supported.
  9. Not AspectJ but AOP[ Go to top ]

    I think you guys are missing the real point of the discussion. Of course you always could do that-hack-that-had-no-name in scripting languages (I did it myself thousands of times in javascript), but I hope we all agree in that a tool is nothing more than a tool -otherwise we'd be starting another boring holly war on programming languages- and that's exactly what AspectJ is - a tool.

    The really important thing is, in my opinion, the formalization of a programming methodology that we all more or less already knew - just the same as what happened with the design patterns of the GoF. The advantages of this are twofold: on the conceptual side we have common ideas on which we can collaboratively operate and, on the practical side, we'll be seeing more and more tools (editors, IDEs) supporting this way of doing stuff - not only for Java, but for python, C++, perl, javascript... maybe even for brainf*ck? ;)