What steps will reproduce the problem?

1. Create class MyCustomTypeAssert
2. Let class MyCustomTypeAssert extend (Generic-) Assert
3. Enjoy the compilation error "... the type org.fest.assertions.Assert is not visible"

What is the expected output? What do you see instead?
The current extension mechanism is un-handy. For the most custom types one needs exactly the methods provided by Assert or GenericAssert. Therefor we would like to be able to use them.

We think that you did make the classes package protected because you want the clients to use the Assertions class which provides static factory methods for all known Assert classes.

The advantage of this way is the single static import of Assertions.assertThat.

The disadvantages are:

1. Assertions is a dependency magnet - the class depends on every Assert class within the framework.
2. It violates the "open-closed-principle". New Assert classes cannot be introduced into the framework without changing the Assertions class.
3. Custom out-of-framework extensions are not possible.

For the static factory methods we suggest to let each Assert class implement the method assertThat(..) which returns the custom Assert class instance.
The Assertions class would not be necessary any more because one could just use the specific methods.
The only little drawback (if you don't use an IDE are the multiple static imports.

Example: Take a custom type:

public class Money
{
  .... do what you want ..
}

Than we would like to write a custom Assert class

public class MoneyAssert extends GenericAssert<Money>
{
  // provide any additional checks not supported by GenericAssert

  public static MoneyAssert assertThat(Money actual)
  {
    return new MoneyAssert(actual);
  }
}

The client usages looks like :

static import your.name.MoneyAssert.assertThat;
...
assertThat(euro("5")).isNotNull();

We are looking forward to any feedback or comments.

Regards,

Jacob Fahrenkrug and Timmo Gierke

Original report: Issue 269 (Google Code)