patterntesting.check.ct.JUnit3Aspect.aj Maven / Gradle / Ivy

Go to download

Show more of this group Show more artifacts with this name
Show all versions of patterntesting-check-ct Show documentation

PatternTesting Check.CT (patterntesting-check-ct) is a quality framework that allows to automatically verify that Architecture/Design recommendations are implemented correctly in the code. It provides different checks of known anti patterns (like using System.out for logging) but provides also a test framework for better testing. The checks are done during compile time (this is the "CT" in Check.CT").

There is a newer version: 2.4.0

Show newest version

/**
 * $Id: JUnit3Aspect.aj,v 1.1 2011/12/22 17:15:08 oboehm Exp $
 *
 * Copyright (c) 2009 by Oliver Boehm
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *   http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express orimplied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 *
 * (c)reated 22.05.2009 by oliver ([email protected])
 */
package patterntesting.check.ct;

import junit.framework.*;

import patterntesting.annotation.check.ct.*;

/**
 * This aspect tries to detect the same JUnit Anti Patterns as
 * JUnit4Aspect. But it does it for tests written with JUnit 3.
 *
 * @see JUnit4Aspect
 * @see SuppressJUnitWarning
 * @{link "http://www.exubero.com/junit/antipatterns.html"}
 *
 * @author oliver
 * @since 22.05.2009
 * @version $Revision: 1.1 $
 */
public aspect JUnit3Aspect {

    /**
     * A JUnit test method is recognized at the prefix test in classes which
     * are derived from junit.framework.TestCase.
     * If you mark a method (or class) with @SuppressJUnitWarning you
     * can suppress the checks of this aspect.
     */
    pointcut withinTestMethod() :
        withincode(public void TestCase+.test*())
        && !@withincode(SuppressJUnitWarning)
        && !@within(SuppressJUnitWarning)
        ;

    /**
     * Using the Wrong Assert
     * 

     * There are a large number of different methods beginning with assert
     * defined in the Assert class. Each of these methods has slightly
     * different arguments and semantics about what they are asserting.
     * However, many programmers seem to stick with a single assertion method:
     * assertTrue, and then force the argument of this method into the required
     * boolean expression.
     */
    declare warning :
        withinTestMethod() && call(public void assertTrue(boolean)) :
            "use other assert method here (e.g. assertEquals)";

    /**
     * Catching Unexpected Exceptions
     * 

     * This anti-pattern seems to catch out a lot of developers who are new to
     * unit testing. When writing production code, developers are generally
     * aware of the problems of uncaught exceptions, and so are relatively
     * diligent about catching exceptions and logging the problem.
     * In the case of unit tests, however, this pattern is completly wrong!
     *
     * @see http://www.exubero.com/junit/antipatterns.html#Catching_Unexpected_Exceptions
     */
    declare warning :
        withinTestMethod() && handler(Throwable+):
            "normally you don't need to catch exceptions inside JUnit tests (use @SuppressJUnitWarning to suppress this warning)";

}