Mark Derricutt's Disturbing Thoughts

My Top Tags

                                       

My Jaiku

Chrome Division – Doomsday Rider

Thursday, 21 August 2008 5:43 A GMT+12

1 Session per VM: Another Scaling Alternative

Wednesday, 20 August 2008 9:47 P GMT+12

The BGGA myth - Functional Java | Google Groups

Wednesday, 20 August 2008 7:33 A GMT+12

Spock's Beard – On A Perfect Day (live)

Wednesday, 20 August 2008 5:57 A GMT+12

Ola Bini: JtestR 0.3.1 Released

Tuesday, 19 August 2008 10:00 P GMT+12

Enslaved – Violet Dawning

Tuesday, 19 August 2008 6:14 A GMT+12

Distributed Messaging with Jetlang and Terracotta

Monday, 18 August 2008 10:17 P GMT+12

The Music of 2008 - week 33

Monday, 18 August 2008 8:57 A GMT+12

There Can Be Only One

Monday, 18 August 2008 8:10 A GMT+12

Search Box

 

WANTED: More control over JDK Annotation Targets

posted Wednesday, 30 April 2008

I recently hit an interesting bug in the TestNG plugin for IntelliJ IDEA. The bug was triggered by a null being set on a Properties instance, and after a hour or so working out what was going on I managed to reproduce the problem with the following test setup:

public class SomeTest {
  public void someMethod() {
    class SomeClass {
      @Test(groups = "test")
      public void thisTestBreaksThings() {
        assert true;
      }
    }
  }

  @Test(dependsOnGroups = "test")
  public void thisTestTriggersABreak() {
    assert true;
  }
}

When running the test method "thisTestTriggersABreak", the IDEA plugin searches for any dependent tests which may be needed to bring into the generated suite. In this instance, the plugin finds the @Test method "thisTestBreaksThings" and adds "SomeClass" to the suite, however a PsiClass instance will return null for anonymous and local classes, which then triggers the NullPointerException later on.

The initial patch for the problem was to simply abort the test run when such an invalid test setup is encountered, with the next step is to add an inspection to highlight, and help prevent the problem - however I wondering if this check should be at the annotation/language level rather than at the IDE plugin level.

Currently an annotation's target member can be defined with @Target (see java.lang.annotation.ElementType), but this doesn't allow us to specify any further context - such as "only methods of public classes" (I'm not even sure what syntax would be appropriate, or possible for this). For this functionality I suspect I'd have go to the annotation processor route, but AFAIK this would only work at compile time, so I'd still be needing IDE specific intentions anyway.

tags:    

links: digg this    del.icio.us    technorati    reddit