alexruiz/fest-assert-2.x

FEST Fluent Assertions 2.x

fest-assert-2.x's Issues

Close fest google code site

containsOnly does not handle null elements

but contains does ...

Move test helper classes from fest-assert-core to fest-test

In order to allow a better modularisation of fest-assert, some classes need to be moved to a common module. First candidates are the test classes (mainly factories), which could be moved to the already existing module fest-test. Only module-specific classes like TestData should be kept in the core module. A first attempt can be seen at the forks:

• https://github.com/gesellix/fest-test and
• https://github.com/gesellix/fest-assert-2.x

These forks already include an example of extracting awt-specific code (ImageAssert) to another module, which is driven by the issue at http://jira.codehaus.org/browse/FEST-485.

Implement ReaderAssert in a similar way as InputStreamAssert

I think that ReaderAssert should be implemented. Basically the functionality should have assertion methods to compare to other Reader as well as some textual support.

From my point of view, it will be cool if you could make an assertion if Reader contains some text. The question is how much similarity with StringAssert should be there?

isLenientEqualsToByIgnoringFields() ignores null fields in expected

The method org.fest.assertions.api.ObjectAssert#isLenientEqualsToByIgnoringFields() behaves like isLenientEqualsToByIgnoringNullFields() regarding null fields on the expected value, while it should behave like isLenientEqualsToByAcceptingFields().

As isEqualToByComparingFields() is implemented using isLenientEqualsToByIgnoringFields(), it is also affected.

I've included a failing test below that exposes the bug on both methods (paraphrasing the javadoc examples).

Tested on version 2.0M5

---

package bugreport;

import org.junit.Test;

import static org.fest.assertions.api.Assertions.assertThat;

public class IsLenientEqualsToByIgnoringFieldsBug {

    private static enum Race {
        HOBBIT, ELF, DWARF, HUMAN
    }

    private static class TolkienCharacter {

        private String name;
        private int age;
        private Race race;

        public TolkienCharacter(String name, int age, Race race) {
            this.name = name;
            this.age = age;
        }

        public String getName() {
            return name;
        }

        public int getAge() {
            return age;
        }

        public Race getRace() {
            return race;
        }
    }

    @Test(expected = AssertionError.class)
    public void testIsLenientEqualToByIgnoringFieldsFailsWhenExpectedFieldIsNull() {

        TolkienCharacter frodo = new TolkienCharacter("frodo", 33, Race.HOBBIT);
        TolkienCharacter mysteriousHobbit = new TolkienCharacter(null, 33, Race.HOBBIT);

        assertThat(frodo).isLenientEqualsToByIgnoringFields(mysteriousHobbit);
    }

    @Test(expected = AssertionError.class)
    public void testIsEqualToByComparingFieldsFailsWhenExpectedFieldIsNull() {

        TolkienCharacter frodo = new TolkienCharacter("frodo", 33, Race.HOBBIT);
        TolkienCharacter mysteriousHobbit = new TolkienCharacter(null, 33, Race.HOBBIT);

        assertThat(frodo).isEqualsToByComparingFields(mysteriousHobbit);
    }



}

Create github page for Fest Assertions

Really easy - only 3 steps, see http://pages.github.com/

Ensure code in master branch follows coding standards and formatting

Found org.fest.assertions.internal.Arrays#assertHasSameSizeAs()

No formatting applied at all.

Goal:

• define at least formatting rules
• apply them automatically before each commit
• don't accept code which does not follow formatting rules (no pull)

Ideally, we should have some coding standards, too (not only mere formatting)

Consider AbstractAssert.is(Predicate)

Consider adding overloaded has()/is() methods to AbstractAssert that apply a com.google.common.base.Predicate. This will make it easier to write fluent tests for codebases that already use Predicates, without having to create Conditions or custom AbstractAssert subclasses.

Example:

public enum Color implements Predicate<Square> {
    BLACK,
    WHITE;

    // Already used elsewhere in the code.
    @Override
    public boolean apply(Square square) {
        return square.hasColor() && square.getColor() == this;
    }
}

public class Square {
    //...

    public boolean hasColor() {
        //...
    }

    public Color getColor() {
        //...
    }
}

public class SquareTest {
    @Test
    public void testDefaultColor {
        // No SquareAssert.isColor() needed
        Square s = new Square();
        assertThat(s).is(Color.WHITE);
    }
}

Unfortunately this will mean a dependency on Google Guava.

Date assert error message improvement

Change from expected:<%s> to be in the past to expecting <%s> to be in the past but was not.

Change from expected:<%s> to be today to expecting <%s> to be today's date <%s> but was not

Change from expected:<%s> to be in the future to expecting <%s> to be in the future but was not.

Give rights to fest developers to update http://fest.easytesting.org site

For the time being, we can only post stuff but not modify the pages.

onProperty support

I cannot find this feature in fest-assert 2.
The PropertySupport is avaible but unused.
I think it's a required feature for fest-assert 2.0 M1 to be iso functionnal with 1.4

If with the new architecture, the design does changes a lot, I can help to implement it.
I think :

• declaring the method in ObjectEnumerableAssert
• delegating the list value extraction to iterables and ObjectArray but still create the new *Assert in the own *Assert
• declaring PropertySupport singleton in Iterables and ObjectArrays as global like Failures

WDYT ?

With 1.x this feature was not avaible for arrays, now it is.

ObjectAssert.isLenientEquals ignores superclass fields

I'm not sure if this is a feature or a bug, but the ObjectAssert.isLenientEquals family of methods checks only the fields of the concrete class and ignores the fields of the superclasses (because that's what Class.getDeclaredFields() does). It should be either documented as such or fixed.

add class related assertions : hasSameClassAs, doesNotHaveSameClassAs, isExactlyInstanceOf, isOfAnyClassIn and counterparts

isOfClass(Class<?> clazz) should check that actual.getClass() == clazz and isNotOfClass() should check !=.
isOfSameClass(Object other) should check that actual.getClass() == other.getClass() and isNotOfSameClass() should check !=.

This methods should be added to AbstractAssert if #31 is satisfied or to ObjectAssert if not.

p.s. any more intuitive names?

Improve error messages

We should display the array/iterable values in a new line because when the message is too long it is hard to read - Mockito has great error messages, let's get some inspiration from it.

Same thing with String assertions, let's put actual and expected in their own lines

Port containsExactly to Fest 2.0

The isEqualTo method allow to verify that the iterable contains exactly some element with order.
This method only take Iterable argument. Could be interesting to take sequence (a colleague of mine would like)

Iterable list = list("Yoda", "Luke"); assertThat(list).isEqualsTo("Yoda", "Luke");

Same for ArrayAssert.
A complementary idea, could be the return of containExactly(...)

Make Fest Assertions more type safe

Each class/interface that has S (self type) parameter should specify an upper bound.
it makes the code more type safe as the returned assertion object is considered by the compiler as the upper bound type.

This was done for EnumerableAssert :

public interface EnumerableAssert<S extends EnumerableAssert<S, T>, T>

As S extends EnumerableAssert, the compiler knows that the returned object in assertion (S) can be considered as of EnumerableAssert type.

We should od the same for ComparableAssert (and probably some other interface/class) :

public interface ComparableAssert<S, A extends Comparable<? super A>>

overridingErrorMessage should be ported in 2.0

For the time being we can't write anymore stuff like :

assertThat(actual.before(day))
       .overridingErrorMessage("<" + actual + "> is not strictly before <" + day + ">")
       .isTrue();

DateAssert isNotBetween error message must be improved

Example :

Date date = parseDate("2010-11-20");
try {
  assertThat(date).isNotBetween("2010-11-19", "2010-11-21");
} catch (AssertionError e) {
  assertThat(e).hasMessage("expected:<2010-11-20T00:00:00> not to be in period '['2010-11-19T00:00:00, '['2010-11-21T00:00:00");
}

problem is in ShouldNotBeBetween private constructor

Properties : add ofType() method to improve API fluency

So you can write :

extractProperty("name", String.class).from(fellowshipOfTheRing)

as

extractProperty("name").ofType(String.class).from(fellowshipOfTheRing)

Implement EnumAssert

I looks like some support for enum classes could be implemented.

The only thing that makes sense for me right now is int EnumAssert.numberOfEnumConstants().

Any other ideas?

Use Cloudbees FOSS Free CI

More inormation here :

• http://www.cloudbees.com/foss/index.cb
• http://www.cloudbees.com/foss/foss-dev.cb

Complete documentation

Doc to add from fest assert 1.x confluence doc :

• JUnit-Specific Features (http://docs.codehaus.org/display/FEST/JUnit-Specific+Features)
• Custom error message (http://docs.codehaus.org/display/FEST/Custom+Error+Messages)
• Comparing to Hamcrest (http://docs.codehaus.org/display/FEST/Comparing+to+Hamcrest)

add S containsAll(Iterable<? extends T> other) to ObjectEnumerableAssert<S, T>

Move isInstanceOf and friends to AbstractAssert

ObjectAssert.isInstanceOf() and ObjectAssert.isInstanceOfAny() can be moved to AbstractAssert so that all it's childs can have this assertions. Also isNotInstanceOf(), isNotInstanceOfAny() may be usefull.

Write an eclipse plugin to convert JUnit assertions to Fest

See this wiki page for conversion based on regexp find and replace:

https://github.com/alexruiz/fest-assert-2.x/wiki/Converting-JUnit-assertions-to-Fest-Assertions

containsOnlyOnce assertion for group (array/iterable)

to complete what has been done in #50

ListAssert : add isEqualTo(T... elements)

Handy to method to avoid user to have to create a List when using isEqualTo(List other).
By the way, does the same as containsExactly(T ...).

I'm not sure we can generalize that to IterableAssert.

Use multiline error message to ease comparison between actual and expected

Refactor StringAssert into CharSequenceAssert so StringBuffer and StringBuilder could be used as well

I think that FEST assertions could refactor the StringAssert into CharSequenceAssert class. The idea is to support both StringBuilder and StringBuffer in a very natural way, without converting them to String which is less readable.

Internally, the CharSequenceAssert should have exactly the same code as StringAssert, just the conversion from CharSequence to String will be done internally. That means almost no changes in code.

Joes suggested, that we could still have a StringAssert class inheriting from CharSequenceAssert, so that StringAssert is still here and you could have StringBuilder and StringBuffer assertions.

Any other opinions on that change?

add Fest logo to the wiki doc

Try to make the text "smoother"

Remove final on methods to provide better extensibility (FEST-475)

In relation to https://jira.codehaus.org/browse/FEST-475 and assertions with timeout.

isEqualTo weird behavior with generics

TolkienCharacter frodo = ... ;
// Won't compile in 2.0M6
assertThat(frodo.getClass()).isEqualTo(TolkienCharacter.class);

Error is :

The method isEqualTo(Class<capture#1-of ? extends TolkienCharacter>) in the type 
AbstractAssert<ObjectAssert<Class<capture#1-of ? extends TolkienCharacter>>,Class<capture#1-of ? extends TolkienCharacter>> 
is not applicable for the arguments (Class<TolkienCharacter>)

Add example in DateAssert javadoc

MapAssert should implement ObjectEnumerableAssert

Map do not extend Collection but in fact it can be treated as an unordered set of Entry'ies. It can be usefull so why not?

New File assertion : hasContent(String content)

We already have :

File actualFile = ... 
File fileWithExpectedContent = ...
assertThat(actualFile).hasSameContentAs(fileWithExpectedContent);

And we would like to have :

File actualFile = ... 
assertThat(actualFile).hasContent("some content");

Add hasTime assertion to DateAssert

And the hasNotTimestamp

assertThat(date).hasTimestamp(1339497115L);

BigDecimalAssert : add isEqualTo(String) and isEqualByComparingTo(String)

Handy methods that convert the given String to a BigDecimal so we can write stuff like :

  @Test
  public void isEqualToAssertionWithBigDecimalAsString()  {
    assertThat(new BigDecimal("10.0")).isEqualTo("10.0");
    try {
      assertThat(new BigDecimal("10.0")).isEqualTo("10.00");
    } catch (AssertionError e) {
      assertThat(e).hasMessage("expected:<10.0[0]> but was:<10.0[]>");
    }
  }

  @Test
  public void isEqualByComparingToAssertionWithBigDecimalAsString()  {
    assertThat(new BigDecimal("10.0")).isEqualByComparingTo("10.0");
    assertThat(new BigDecimal("10.0")).isEqualByComparingTo("10.00");
    try {
      assertThat(new BigDecimal("10.0")).isEqualTo("20.0");
    } catch (AssertionError e) {
      assertThat(e).hasMessage("expected:<[2]0.0> but was:<[1]0.0>");
    }
  }

ShouldHaveEqualContent unexpected MissingFormatArgumentException

This happened to me when I tried to compare two files content containing %s string.

the error message was : file:<%s> and file:<%s> do not have equal content:+diffs

If diffs contains a format specifier because of different lines containing some, a MissingFormatArgumentException is thrown as String.format fails to find the format specifier from diffs.

Fix Maven warnings regarding missing plugin versions

Maven 3.x complains:

/usr/java/jdk1.7.0_02/bin/java -Dclassworlds.conf=/home/ansgar/opt/apache-maven-3.0.4/bin/m2.conf -Dmaven.home=/home/ansgar/opt/apache-maven-3.0.4 -Didea.launcher.port=7532 -Didea.launcher.bin.path=/home/ansgar/opt/idea-IU-117.117/bin -Dfile.encoding=UTF-8 -classpath /home/ansgar/opt/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar:/home/ansgar/opt/idea-IU-117.117/lib/idea_rt.jar com.intellij.rt.execution.application.AppMain org.codehaus.classworlds.Launcher --no-plugin-registry --fail-fast --no-plugin-updates --strict-checksums --update-snapshots -f /home/ansgar/git-repositories/easytesting.org/github/fest-assert-2.x/pom.xml clean verify
[WARNING] Command line option -npu is deprecated and will be removed in future Maven versions.
[WARNING] Command line option -npr is deprecated and will be removed in future Maven versions.
[INFO] Scanning for projects...
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for org.easytesting:fest-assert-core:jar:2.0M7-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-resources-plugin is missing. @ org.easytesting:fest:1.0.11, /home/ansgar/.m2/repository/org/easytesting/fest/1.0.11/fest-1.0.11.pom, line 189, column 15
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ org.easytesting:fest:1.0.11, /home/ansgar/.m2/repository/org/easytesting/fest/1.0.11/fest-1.0.11.pom, line 196, column 15
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ org.easytesting:fest:1.0.11, /home/ansgar/.m2/repository/org/easytesting/fest/1.0.11/fest-1.0.11.pom, line 212, column 15
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-site-plugin is missing. @ org.easytesting:fest:1.0.11, /home/ansgar/.m2/repository/org/easytesting/fest/1.0.11/fest-1.0.11.pom, line 205, column 15
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-source-plugin is missing. @ org.easytesting:fest:1.0.11, /home/ansgar/.m2/repository/org/easytesting/fest/1.0.11/fest-1.0.11.pom, line 222, column 15
[WARNING] 'reporting.plugins.plugin.version' for org.apache.maven.plugins:maven-site-plugin is missing. @ org.easytesting:fest:1.0.11, /home/ansgar/.m2/repository/org/easytesting/fest/1.0.11/fest-1.0.11.pom, line 314, column 15
[WARNING] 'reporting.plugins.plugin.version' for org.codehaus.mojo:javancss-maven-plugin is missing. @ org.easytesting:fest:1.0.11, /home/ansgar/.m2/repository/org/easytesting/fest/1.0.11/fest-1.0.11.pom, line 318, column 15
[WARNING] 'reporting.plugins.plugin.version' for org.apache.maven.plugins:maven-javadoc-plugin is missing. @ org.easytesting:fest:1.0.11, /home/ansgar/.m2/repository/org/easytesting/fest/1.0.11/fest-1.0.11.pom, line 322, column 15
[WARNING] 'reporting.plugins.plugin.version' for org.codehaus.mojo:jdepend-maven-plugin is missing. @ org.easytesting:fest:1.0.11, /home/ansgar/.m2/repository/org/easytesting/fest/1.0.11/fest-1.0.11.pom, line 350, column 15
[WARNING] 'reporting.plugins.plugin.version' for org.codehaus.mojo:findbugs-maven-plugin is missing. @ org.easytesting:fest:1.0.11, /home/ansgar/.m2/repository/org/easytesting/fest/1.0.11/fest-1.0.11.pom, line 354, column 15
[WARNING] 'reporting.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-report-plugin is missing. @ org.easytesting:fest:1.0.11, /home/ansgar/.m2/repository/org/easytesting/fest/1.0.11/fest-1.0.11.pom, line 358, column 15
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
´´´

Should be fixed. 

What needs to be done:
- add plugin versions to parent POM
- test the new parent POM works great for FEST-Assert (install snapshot + build FEST-Assert)
- release parent POM
- update parent pom of FEST-Assert to new parent version

While we're at it: 
- we could update the plugin versions to the latest released versions
- plus review the plugins for redundant phase bindings (like source/javadoc plugin).

Implement ClassAssert

Assertions for Class objects.
It's of limited use but if you are writing a classloader or a code generation library it may be very convenient.

New File assertions : canRead(), canWrite() and canExecute()

It could be convenient to have FileAssert providing:

    assertThat(file).canRead();
    assertThat(file).canWrite();
    assertThat(file).canExecute();

as it provides :

    assertThat(file).isDirectory();
    assertThat(file).isFile();

(I can take care of the implementation)

maven build should assure that we build a java 5 compatible version

It is not enough to have source and target set 1.5 in maven compiler plugin configuration :

<source>1.5</source>
<target>1.5</target>

It is mentioned in a note of the plugin doc suggesting :
To avoid this issue, you can either configure the compiler's boot classpath to match the target JRE or use the Animal Sniffer Maven Plugin to verify your code doesn't use unintended APIs.

StringAssert containsOnlyOnce assertion

Moved from https://jira.codehaus.org/browse/FEST-487.

MapAssert should have containsKey(), containsValue() and counterparts

This should be possible:

Map<String, Integer> map = new HashMap<String, Integer>();
assertThat(map).doesNotContainKey("test1").containsValue(2);

Decision to make: should this methods take generic types (containsKey(K key) and containsValue(V value)) or Objects? This methods in Map interface take Objects because their semantics are defined in terms of equals() (which takes Object) so the "correct" decision is to take Objects. But on practice this leads to coding errors when using this methods - adding a type check can at least prevent passing a wrong variable type (think about IDE's autocompletion).

My opinion - it should take generic types. If someone wants to assert with some other type it's still possible to write

Map<String, Integer> map = new HashMap<String, Integer>();
assertThat(map.doesNotContainKey(new Object())).isTrue();

Ensure all commits can be traced back to their contributors, so we have a chance of contacting the original authors

Found code lines with user name "unknown"

Example: FEST-Assert

commit 2862f1e
Author: unknown <Nicolas@.(none)>

If we can't reach the authors, we might run into serious trouble when proving "IP Clearance". See: http://incubator.apache.org/ip-clearance/index.html

Not that we should try to prove it today, but if we cannot even reach out to the authors, we'll go bust in this respect.

We basically lose our chance to prove that we have not stolen any code.

Imagine some d_ckhead wants to f_ck up this project like this:

Q: Where does this code come from?
A: we wrote it!
Q: who is we?
A: okay, here's a list of authors!
Q: who is "unknown"?
A: ...
=> OK, so you stole code from $ANYWHERE$, I'll tell everybody.

Properties.from should use Iterable

For the time being the method is :

public List<T> from(Collection<?> c)

It should be :

public Iterable<T> from(Iterable<?> c)

This will allow to combine extracting properties and filter features which is not possible right now since filter returns an Iterable, real life ex :

Iterable<Alias> filteredAliases = filter(aliase).with("isin").equalsTo("AT000000STR1").get();
assertThat(extractProperty("ticker").from(filteredAliases)).containsExactly("STR AV Equity");

Custom assertions no longer have access to their descriptions

Under 1.4, a customer assertion like:

private AgreementAssertion hasAssociatedPolicySetCount(int expectedSize, Predicate<String> matchingString) {
  int size = 0;
  try {
    for (PartyProduct partyProduct : AgreementUtils.findAssociatedPartyProduct(agreement)) {
      if (matchingString.apply(partyProduct.getProduct().getCode())) {
        size += partyProduct.getPolicySets().size();
      }
    }
  } catch (PartyProductException e) {
     // ignore errors - no count increase
  }

  assertThat(size)
    .describedAs(description())
    .isEqualTo(expectedSize);

   return this;
 }

Can reuse the configured description by called description(), under the new AbstractAssertion this is no longer available. The class does contain a descriptionText() method which is package protected and annotated as @VisibeForTesting - could this be made public, or another suitable means for accessing the assertion description be added back.

ListAssert inherits from IterableAssert and remove AbstractIterableAssert ?

I just remember of this TODO.
For recall, ListAssert header is :

public class ListAssert<T> extends AbstractIterableAssert<ListAssert<T>, List<T>, T> implements IndexedObjectEnumerableAssert<T>

I think we should, there is not reason against and to have better logical hierarchy.

ObjectArrayAssert contains methods should use T parameter instead of Object

Or maybe ? extends T

Filters should support null value

We should be able to write :

filter(team).with("id", null).get()