AssertJ is a library providing easy to use rich typed assertions

Overview

AssertJ - Fluent assertions for java

Github CI status Github Cross-Version status Maven Central Javadocs Quality Gate Status

AssertJ provides a rich and intuitive set of strongly-typed assertions to use for unit testing (with JUnit, TestNG or any other test framework).

You can ask questions in stackoverflow (assertj tag) and make suggestions by simply creating an issue.

AssertJ's goals

AssertJ's ambition is to provide a rich and intuitive set of strongly-typed assertions for unit testing.

The idea is that disposal assertions should be specific to the type of the objects we are checking when writing unit tests. If you're checking the value of a String, you use String-specific assertions. Checking the value of a Map? Use Map-specific assertions to easily check the contents of the map.

AssertJ's assertions are super easy to use: just type assertThat(underTest). and use code completion to show you all assertions available.

Assertion missing? Please create an issue to discuss it and even better contribute to the project!

AssertJ is composed of several modules:

Want to contribute?

You are encouraged to contribute any missing useful assertions.

Please read the contributing section and raise a PR!

Issues
  • 3.9.1 has bad performance regression

    3.9.1 has bad performance regression

    Summary

    After upgrading to 3.9.1, I notice a regression in term of performance. By digging down, I notice that it spends a lot of time in the following code

      public static TypeComparators defaultTypeComparators() {
        TypeComparators comparatorByType = new TypeComparators();
        comparatorByType.put(Double.class, new DoubleComparator(DOUBLE_COMPARATOR_PRECISION));
        comparatorByType.put(Float.class, new FloatComparator(FLOAT_COMPARATOR_PRECISION));
        return comparatorByType;
      }
    

    It sounds like it performs too much memory allocation and reflection cost on the following stack trace.

    java.lang.Class.getEnclosingMethod0() Class.java (native)
    java.lang.Class.getEnclosingMethodInfo() Class.java:1072
    java.lang.Class.getEnclosingClass() Class.java:1272
    java.lang.Class.getSimpleBinaryName() Class.java:1443
    java.lang.Class.getSimpleName() Class.java:1309
    org.assertj.core.internal.TypeComparators$$Lambda$77.apply(Object)
    java.util.Comparator.lambda$comparing$77a9974f$1(Function, Object, Object) Comparator.java:469
    java.util.Comparator$$Lambda$78.compare(Object, Object)
    java.util.TreeMap.compare(Object, Object) TreeMap.java:1295
    java.util.TreeMap.put(Object, Object) TreeMap.java:538
    org.assertj.core.internal.TypeComparators.put(Class, Comparator) TypeComparators.java:99
    org.assertj.core.internal.TypeComparators.defaultTypeComparators() TypeComparators.java:48
    org.assertj.core.api.AbstractIterableAssert.<init>(Iterable, Class) AbstractIterableAssert.java:112
    org.assertj.core.api.FactoryBasedNavigableIterableAssert.<init>(Iterable, Class, AssertFactory) FactoryBasedNavigableIterableAssert.java:32
    org.assertj.core.api.IterableAssert.<init>(Iterable) IterableAssert.java:49
    org.assertj.core.api.Assertions.assertThat(Iterable) Assertions.java:2586
    

    This additional overhead is caused by the change from HashMap to TreeMap and the use of Comparator.comparing(Class::getSimpleName)

    assertj 3.8.0 does not have this problem.

    opened by testn 63
  • Java module descriptor for `org.assertj.core`

    Java module descriptor for `org.assertj.core`

    Old caption

    [ByteBuddy] NoClassDefFoundError: java.lang.instrument.Instrumentation

    Summary

    Running tests included in JUnit 5's documentation project (backing the User Guide) on the class-path works fine. Converting those tests and demos into a Java module and running it on the module-path fails with several errors. One of the error is related to AssertJ/ByteBuddy.

    Found this issue while working on https://github.com/junit-team/junit5/issues/1877

    /cc @raphw

      JUnit Jupiter:EngineTestKitAllEventsDemo:verifyAllJupiterEvents()
        MethodSource [className = 'example.testkit.EngineTestKitAllEventsDemo', methodName = 'verifyAllJupiterEvents', methodParameterTypes = '']
        => java.lang.IllegalArgumentException: Could not create type
           [email protected]/org.assertj.core.internal.bytebuddy.TypeCache.findOrInsert(TypeCache.java:154)
           [email protected]/org.assertj.core.internal.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:365)
           [email protected]/org.assertj.core.api.SoftProxies.createSoftAssertionProxyClass(SoftProxies.java:118)
           [email protected]/org.assertj.core.api.SoftProxies.createSoftAssertionProxy(SoftProxies.java:104)
           [email protected]/org.assertj.core.api.AbstractSoftAssertions.proxy(AbstractSoftAssertions.java:31)
           [...]
         Caused by: java.lang.NoClassDefFoundError: java/lang/instrument/Instrumentation
           [email protected]/org.assertj.core.internal.bytebuddy.utility.JavaModule$Dispatcher$CreationAction.run(JavaModule.java:270)
           [email protected]/org.assertj.core.internal.bytebuddy.utility.JavaModule$Dispatcher$CreationAction.run(JavaModule.java:251)
           java.base/java.security.AccessController.doPrivileged(Native Method)
           [email protected]/org.assertj.core.internal.bytebuddy.utility.JavaModule.<clinit>(JavaModule.java:45)
           [email protected]/org.assertj.core.internal.bytebuddy.dynamic.loading.ClassInjector$UsingReflection$Dispatcher$CreationAction.run(ClassInjector.java:454)
           [...]
         Caused by: java.lang.ClassNotFoundException: java.lang.instrument.Instrumentation
           java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
           java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
           java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
           [...]
    

    Side note: Nice to see the AssertJ's version 3.12.2 compiled into its module! :+1:

    opened by sormuras 61
  • Skeleton PathAssert, plus tests -- NOT FOR INCLUSION. Yet.

    Skeleton PathAssert, plus tests -- NOT FOR INCLUSION. Yet.

    Skeleton based on existing code. I modeled it on FileAssert. In fact I saw nothing related to anything java.nio.file in the code, so I created it from scratch...

    Preview only. I know the coding style does not fit; knowing that I use IDEA, do you happen to have a style file available?

    Also, about error messages: there seem to be a lot of factories; FileAssert seems to basically use one per message! Is that on purpose? Can I create a single factory for Path-specific operations (including exists, non exists and absolute)?

    Please comment! I'll add more test when the base is good enough for you.

    opened by fge 47
  • SoftAssertions for JUnit Jupiter should reset tracked exceptions between tests

    SoftAssertions for JUnit Jupiter should reset tracked exceptions between tests

    Overview

    The following code looks up tracked exceptions in an instance field.

    https://github.com/joel-costigliola/assertj-core/blob/9692f7dc339765e9d7ef2725c89b3241c613268f/src/main/java/org/assertj/core/api/JUnitJupiterSoftAssertions.java#L45

    The problem with doing that is that the tracked exceptions do not get reset between test method invocations if the test class is configured with @TestInstance(PER_CLASS) lifecycle semantics, since the test instance is cached along with the instance of JUnitJupiterSoftAssertions stored in an instance field.

    I became aware of this due to the following comment in JUnit's issue tracker: https://github.com/junit-team/junit5/issues/1500#issuecomment-459720295

    Affected Extensions

    • JUnitJupiterSoftAssertions
    • JUnitJupiterBDDSoftAssertions
    • any other extensions implemented in a similar manner

    Proposals

    Modify JUnitJupiterSoftAssertions so that it implements JUnit Jupiter's BeforeEachCallback extension API and clears the collected errors in SoftProxies before each test method.

    Another option would be to store the collected errors in Jupiter's ExtensionContext.Store for the currently executing scope.

    Relate Issues

    • #1229
    opened by sbrannen 44
  • Recursive comparison api improvements

    Recursive comparison api improvements

    Recursive comparison api

    Here's an example to give users an idea of what it looks like:

    assertThat(person).usingRecursiveComparison()
                      .ignoringNullFields()
                      .ignoringFields("name", "age")                                                 
                      .forcingRecursiveComparisonFor(Child.class, Sister.class)
                      .isEqualTo(expectedPerson);
    

    This will be in Beta as it might change according to people's feedback.

    Requirements

    Recursive comparison Fluent API configuration

    Implements an easy to use/discover API as in:

    assertThat(person).usingRecursiveComparison()
                      .ignoringNullFields()
                      .ignoringFields("name", "age")                                                 
                      .isEqualTo(expectedPerson);
    
    • [x] expose ignoring actual null fields
    • [x] expose ignoring fields
    • [x] expose ignoring overridden equals
    • [x] expose setting a comparison strategy per fields/types
    • [x] expose enabling strict type checking
    • [x] documentation

    Ignoring fields in comparison

    Users can specify the comparison to ignore all null fields in the object under test.

    Users can specify to ignore specific fields in the object under test:

    • giving their full path, ex: person.sister.name
    • by regex, ex: .*name means name, person.name and person.sister.name are ignored.

    Note if you ignore specific field, all sub fields are ignored too, for example if person is ignored then person.name, person.address, person.address.number are ignored too.

    Nice to have: report all the fields ignored in the comparison

    status

    • [x] ignore all null fields
    • [x] ignore fields specified with a full path
    • [ ] fail if an ignored fields specified with a full path does not match any field
    • [x] ignore fields specified with a regex
    • [x] report the fields configured to be ignored in the comparison
    • [ ] report all the fields actually ignored in the comparison (to show which fields the regex matched)
    • [ ] documentation

    Allow to use overridden equals method or not

    By default the recursive comparison will use equals if it had been overridden but users should be able to specify to ignore overridden equals methods and compare objects field by field.

    This can be done:

    • for all types matching given regexes
    • a specific given list of types with forcingRecursiveComparisonFor(Child.class, Sister.class)
    • a specific given list of fields with forcingRecursiveComparisonForFields("child", "sister") Nice to have

    Example:

    assertThat(person).usingRecursiveComparison()
                      .forcingRecursiveComparisonFor(Child.class, Sister.class)
                      .forcingRecursiveComparisonForFields("name", "city")
                      .isEqualTo(expectedPerson);
    

    status

    • [x] disable use of overridden equals method for types matching given regexes
    • [x] disable use of overridden equals method for given types
    • [x] disable use of overridden equals method for given fields
    • [x] disable use of overridden equals method for all fields
    • [x] documentation

    Specify a comparison strategy per type or fields

    Users should be able to specify a comparator for a given type or fields:

    • usingComparatorForType(String.class, caseInsensitiveComparator) for all types
    • usingComparatorForFields(caseInsensitiveComparator, "name", "city") a specific given list of fields (vararg)

    To keep the API simple once a comparator for a given type is registered it should be used at any level, collection element or collection element field.

    Field comparators take precedence over type ones as they are more fine grained.

    Once a comparator is registered for a type or a field, it replaces the recursive comparison when these types/fields are being compared.

    status

    • [x] enable a comparison strategy per type
    • [x] enable a comparison strategy per fields
    • [x] documentation

    Strict/lenient type checking

    This will specify if two instances with the same fields but from different classes are considered equals, it allows for example to compare a Person with a PersonDto. If the check is strict the expected object class must be compatible (i.e. extends) actuals, so if Employee inherits Person one can compare a person with an employee (but not an employee with a person. The check is performed on the root objects and their fields.

    By default the check is lenient but it can be made strict to fail the comparison.

    status

    • [x] enable strict type checking
    • [ ] lenient type checking should allow comparing collections of different type (ex TreeSet vs HashSet).
    • [ ] documentation

    Handle cycles

    The recursive comparison should handle cycles, for example when a -> b -> c -> a.

    status

    • [ ] more tests with cycles
    • [ ] documentation

    Map support

    Maps entries should be considered as fields. See if it is possible and relevant to report all compared maps internal differences (size, missing elements, elements differences, order when order is consistent ...) instead just reporting that the maps differ.

    status

    On hold at the moment as it is not crystal what can be achieved reasonably.

    • [ ] map support
    • [ ] documentation

    Iterable/array support

    At the moment assertThat(Iterable/array) does not expose usingRecursiveComparison() which makes it cumbersome to test them field/field.

    The comparison by default fails if we compare an ordered collection to an unordered one but this should be configurable

    Nice to have: ignores order in comparison (by default elements are compared in order for ordered collection). Nice to have: allow to compare ordered collections with unordered one. (this should be disabled by default) Nice to have: allow to compare array with ordered collections like list. (this should be disabled by default)

    Example:

    assertThat(fellowshipOfTheRing).usingRecursiveComparison()
                                   .contains(frodo, sam, merry, pippin, gandalf, 
                                             legolas, boromir, aragorn, gimli);
    

    status

    • [ ] provide elements recursive comparison out of the box for iterable assertions
    • [x] ignores order in comparison (by default elements are compared in order for ordered collection).
    • [x] allow to compare ordered collections with unordered one. (this should be disabled by default)
    • [ ] allow to compare array with ordered collections like list. (this should be disabled by default)
    • [ ] documentation

    Error reporting

    A failure must report the recursive comparison specification:

    • comparators used per type
    • comparators used per fields
    • ignored fields
    • when overridden equals are used and not used

    The failure should show the number of differences and describe them all.

    A difference describes fields by their full path from the root object, the actual value, the expected one and the comparison used if the user specified one. Values are represented with AssertJ standard representation or the one set by the user.

    Actual and expected values type should be displayed when strict type checking is enable.

    The differences reported must be ordered by path alphabetically.

    Difference report example:

    person.sister.name differs: 
    - actual value  : "Sansa"
    - expected value: "Arya"
    - comparison was performed with caseInsensitiveComparator 
    

    The path to field must support maps and adress https://github.com/joel-costigliola/assertj-core/issues/1303.

    status

    • [x] basic error reporting
    • [x] error reporting : show comparators used
    • [ ] error reporting : list ignored fields
    • [x] error reporting : show that actual's null field were ignored in the comparison
    • [ ] error reporting : show which overridden equals were used
    • [ ] error reporting : the path to field must support maps
    • [ ] error reporting : report the index of the indexes of ordered collection field element, ex: friends[1].number
    • [x] error reporting : the differences reported must be ordered by path alphabetically

    Globally configuring the recursive comparison behavior

    To avoid repeating the same recursive configuration before each assertion, AssertJ should provide:

    • a global way to configure the default recursive comparison behavior
    • a way capture easily on the recursive comparison configuration in order to reuse it

    Changing the default recursive comparison behavior before all tests

    AssertJ will extend the mechanism used to configure Representation.

    Capture the recursive comparison setting to reuse it

    If users don't want to change the default behavior globally but on a smaller scope, it will possible to capture a recursive comparison specification and reuse it.

    Example:

    // default behavior
    RecursiveComparisonSpecification recursiveComparisonSpecification =  new RecursiveComparisonSpecification();
    recursiveComparisonSpecification.ignoreNullFields();
    recursiveComparisonSpecification.forceRecursiveComparisonFor(Child.class, Sister.class);
    
    assertThat(person).usingRecursiveComparison(recursiveComparisonSpecification)
                      .isEqualTo(expectedPerson);
    
    assertThat(person2).usingRecursiveComparison(recursiveComparisonSpecification)
                       .isEqualTo(expectedPerson2);
    

    The example above is equivalent to this where we have to repeat call to ignoringNullFields and forcingRecursiveComparisonFor for each assertions:

    assertThat(person).usingRecursiveComparison()
                      .ignoringNullFields()
                      .forcingRecursiveComparisonFor(Child.class, Sister.class)
                      .isEqualTo(expectedPerson);
    
    assertThat(person2).usingRecursiveComparison(recursiveComparisonSpecification)
                       .ignoringNullFields()
                       .forcingRecursiveComparisonFor(Child.class, Sister.class)
                       .isEqualTo(expectedPerson2);
    

    status

    • [ ] provide a way to globally configure the recursive comparison behavior

    Tests checklist

    The recursive comparison specification must be transferred after calling methods that change the object under test: extracting, asString ...

    status

    • [ ] test recursive comparison is propagated

    Initial issue description

    The current way comparing objects recursively is starting to pollute the api, the methods introduced for the recursive comparison don't apply for the other assertion cluttering the assertj api, ex usingComparatorForType.

    I would like to introduce a separate API to use recursive comparison allowing to fine tune the comparison behavior.

    API rough draft (please criticize it !)

    import static RecursiveComparisonSpecification;
    
    // ignoringNullFields() comes from RecursiveComparisonSpecification
    assertThat(person).usingRecursiveComparison(ignoringNullFields()
                                               .ignoringFields("name", "age")                                                 
                                               .forcingRecursiveComparisonFor(Child.class, Sister.class))
                      .isEqualTo(expectedPersont)
    
    recursive api 
    opened by joel-costigliola 35
  • Use byte buddy instead of cglib

    Use byte buddy instead of cglib

    Check List:

    • Related to: #928
    • Unit tests : NA
    • Javadoc with a code example (API only) : NA

    With this PR I am dropping cglib and adding bytebuddy as a dependency. I still have not removed the shading. One test is failing due to ClassCastException, and I am not entirely sure how I can resolve it. Maybe @raphw can help out a bit 😄. The issue is in the ErrorCollector#intercept method.

    I think that we should not be shading bytebuddy. Their recommendation is that you should shade if you use the exposed ASM, which I am not. Also the other major players such as Mockito are pulling it as a dependency (we could do it as an optional one or provide 2 modules, one with normal assertions and another with soft).

    Something that I noticed with bytebuddy is that you can theoretically generate the bytecode and ship that as part of the AssertJ release (that way you have no dependency on anything during runtime)

    opened by filiphr 34
  • Bytes assertions enhancements - better readability

    Bytes assertions enhancements - better readability

    My proposition for assertions arrays:

    assertThat("zólc".getBytes()).contains("żółć".getBytes("ISO-8859-2"));
    
    java.lang.AssertionError:
    Expecting:
    <[7A:C3:B3:6C:63]>
    to contain:
    <[BF:F3:B3:E6]>
    but could not find:
    <[BF:F3:E6]>
    

    This is more readable than:

    java.lang.AssertionError:
    Expecting:
    <[0x7A, 0xC3, 0xB3, 0x6C, 0x63]>
    to contain:
    <[0xBF, 0xF3, 0xB3, 0xE6]>
    but could not find:
    <[0xBF, 0xF3, 0xE6]>
    

    Simple values comparision without changes:

    assertThat((byte) 0xff).isEqualTo((byte) '3');
    
    org.junit.ComparisonFailure:
    Expected :0x33
    Actual   :0xFF
    

    What do you think?

    opened by mariuszs 28
  • Add method to use SoftAssertions with any custom Assertions

    Add method to use SoftAssertions with any custom Assertions

    Add static assertSoftly method to be able to use any common and custom assertion side by side within on assertSoftly call/scope e.g.

            SoftAssertions.assertSoftly(
                    () -> Assertions.assertThat("test1").isEqualTo("bar"),
                    () -> GuavaAssertions.assertThat(...).contains(...),
                    () -> MyAssertion.assertThat(...).contains(...)
            );
    

    Check List:

    • Unit tests : NO
    • Javadoc with a code example (API only) : NO
    opened by qoomon 28
  • Introduce XPath like assertions

    Introduce XPath like assertions

    It would quite useful to have XPath like assertions (similar to what it is available in XMLUnit but with a fluent interface of course :-) )

    For example:

    String mySolarSystemXML = "<solar-system><planet name='Earth' position='3' supportsLife='yes'/><planet name='Venus' position='4'/></solar-system>";
    
    assertXpathExists("//planet[@name='Earth']", mySolarSystemXML);
    
    assertXpathNotExists("//star[@name='alpha centauri']",
                         mySolarSystemXML);
    
    assertXpathsEqual("//planet[@name='Earth']",
                      "//planet[@position='3']", mySolarSystemXML);
    
    assertXpathsNotEqual("//planet[@name='Venus']",
                         "//planet[@supportsLife='yes']",
                         mySolarSystemXML);
    

    [Example from http://xmlunit.sourceforge.net/userguide/html/index.html#Xpath%20Tests ]

    opened by gualtierotesta 26
  • Improve the way to assert exceptions

    Improve the way to assert exceptions

    This commit makes it possible to write things like this:

    assertThat((ExceptionalRunnable) () -> { 
        throw new IllegalArgumentException(); 
    }).toThrow(IllegalArgumentException.class);
    

    or on Java 7:

    assertThat(new ExceptionalRunnable() {
      @Override
      public void run() throws Exception {
        throw new IllegalArgumentException();
      }
    }).toThrow(IllegalArgumentException.class);
    

    instead of:

    try {
        throw new IllegalArgumentException();
        failBecauseExceptionWasNotThrown(IllegalArgumentException.class);
    } catch (IllegalArgumentException ignored) {}
    
    opened by Turbo87 26
  • Assertj multimodule build

    Assertj multimodule build

    Summary

    We tests assertj core with integration tests to validate junit 4, testng and osgi integration, this works but is more a workaround to simulate different environments.

    A better solution consists in defining a multi module project where junit 4 and testng checks will be done in their own modules which are closer to real project using assertj.

    Modules:

    • assertj-core
    • assertj-guava
    • assertj-db
    • assertj-joda
    • assertj-neo4j
    • assertj-examples
    • assertj-core-junit4-with-opentest4j and remove the corresponding integration tests in assertj-core
    • assertj-core-junit4-with-testng and remove the corresponding integration tests in assertj-core
    • assertj-core-osgi-tests and remove the corresponding integration tests in assertj-core

    Github actions

    We need to update our CI actions to build the multimodule project.

    A commit in main should trigger all the modules build but the assertj core CI build should only reports errors when any of these modules build fail:

    • assertj-core module
    • assertj-core-junit4-with-opentest4j
    • assertj-core-junit4-with-testng
    • assertj-core-osgi-tests

    The assertj core should not fail if an assertions module fails (ex: assertj-guava), this should be reported by the assertion module build itself.

    improvement for: team-attention 
    opened by joel-costigliola 0
  • Add AbstractThrowableAssert#causesChain to simplify performing assertions on a chain of throwables

    Add AbstractThrowableAssert#causesChain to simplify performing assertions on a chain of throwables

    Check List:

    • Fixes #1147 (ignore if not applicable)
    • Unit tests : YES
    • Javadoc with a code example (on API only) : YES
    • PR meets the contributing guidelines

    Following the contributing guidelines will make it easier for us to review and accept your PR.

    opened by slinkydeveloper 2
  • modified all subclasses of FilesBaseTest to use real filesystem file

    modified all subclasses of FilesBaseTest to use real filesystem file

    Check List:

    This is my first PR on Assertj. I will appreciate if I can get any suggestions on how to improve my work for this and future issues.

    opened by ahmadsadeed 2
  • Extracting elements on List of Maps throws exception on unknown fields

    Extracting elements on List of Maps throws exception on unknown fields

    Summary

    We recently upgraded AssertJ to 3.21.0, we skipped 3.20 (because we got the upgrade through Spring Boot from 2.5 to 2.6) and we started getting failures in places that were working before. This is caused by the fix that was done in #2111.

    The example below runs fine with 3.19. However, it fails on 3.21.

    In my honest opinion the fact that hasFieldOrProperty used to do map.get(name) is correct. If I am extracting values from a map, I might be extracting sparse values. The fact that other frameworks are using a Map as the actual object and not overriding the method properly is entirely up to the frameworks to fix that on their side.

    Example

    List<Map<String, Object>> elements = new ArrayList<>();
    Map<String, Object> map = new HashMap<>();
    map.put("name", "Yoda");
    elements.add(map);
    map = new HashMap<>();
    map.put("name", "Luke");
    map.put("location", "Tatooine");
    
    assertThat(elements)
            .extracting("name", "location")
            .containsExactlyInAnyOrder(tuple("Yoda", null), tuple("Luke", "Tatooine"));
    
    

    There is a workaround for this if I use .extracting(m -> m.get("name"), m -> m.get("location")). However, that is really verbose and I would argue that it is against the spirit of AssertJ

    opened by filiphr 4
  • [soft] Soft assertions on collections not working on collections

    [soft] Soft assertions on collections not working on collections

    Summary

    Regression in soft assertions on collections in AssertJ 3.20.0 under OSGi.

    Example

    @Test
    void test() {
        SoftAssertions s = new SoftAssertions();
        List<?> o = new ArrayList<>();
        s.assertThat(o).hasSize(0);
    }
    

    With AssertJ 3.19.0, the above code compiles and runs fine under JUnit 5 in OSGi..

    With AssertJ 3.20.0 and above the above code still compiles but fails at runtime with the following error:

    java.lang.NoSuchMethodError: org.assertj.core.api.SoftAssertions.assertThat(Ljava/util/List;)Lorg/assertj/core/api/ProxyableListAssert;

    If I extract the body of that and run it in a main() method from a standalone (non-OSGi) Java class, it seems to work.

    cc: @bjhargrave

    opened by kriegfrj 1
  • Issue 2060 StringAssert: add variants with

    Issue 2060 StringAssert: add variants with "Ignoring"

    Check List:

    • Fixes #2060 (partially)
    • Unit tests : YES
    • Javadoc with a code example (on API only) : YES
    • PR meets the contributing guidelines

    Following the contributing guidelines will make it easier for us to review and accept your PR.

    opened by spring1627 4
  • Offset with float[] assertion doesn't have the same behavior as Offset with float assertion

    Offset with float[] assertion doesn't have the same behavior as Offset with float assertion

    Summary

    Offset with float[] assertion doesn't have the same behavior as Offset with float assertion.

    Tested with assertj-3.21.0.

    Example

    assertThat(0.2f).isEqualTo(0.7f, within(0.5f)); // pass
    assertThat(new float[]{0.2f}).containsExactly(new float[]{0.7f}, within(0.5f)); // fail but should pass
    

    Expecting actual: [0.2f] to contain exactly (and in same order): [0.7f] but some elements were not found: [0.7f] and others were not expected: [0.2f] when comparing values using float comparator at precision 0.5

    bug 
    opened by juherr 3
  • Is directory recursively containing string

    Is directory recursively containing string

    Check List:

    Following the contributing guidelines will make it easier for us to review and accept your PR.

    for: team-attention 
    opened by spring1627 1
  • flatExtracting/flatMap for iterable/array should throw a proper assertion error if any element is null

    flatExtracting/flatMap for iterable/array should throw a proper assertion error if any element is null

    Summary

    Similar to https://github.com/assertj/assertj-core/issues/2401 but for flatExtracting/flatMap.

    There are quite a few variations to cover and tests;

    • [ ] flatExtracting(Function), flatMap(Function), flatExtracting(ThrowingExtractor) and flatMap(ThrowingExtractor), will be fixed by changing doFlatExtracting, tests needed for the 4 methods exposed in the API.
    • [ ] flatExtracting(Function...), flatExtracting(ThrowingExtractor...), flatMap(Function...) and flatMap(ThrowingExtractor...), will be fixed by changing flatExtractingForProxy, tests needed for 4 methods exposed in the API.
    good first issue 
    opened by joel-costigliola 0
  • extracting/map for iterable/array should throw a proper assertion error if any element is null

    extracting/map for iterable/array should throw a proper assertion error if any element is null

    Summary

    Similar to https://github.com/assertj/assertj-core/issues/2401 but for iterable/arrays

    There are quite a few variations to cover and tests;

    • [ ] extracting(Function), map(Function), extracting(ThrowingExtractor) and map(ThrowingExtractor), will be fixed by changing internalExtracting, tests needed for the 4 methods exposed in the API.
    • [ ] extracting(Function...) and map(Function...), will be fixed by changing extractingForProxy, tests needed for both
    good first issue 
    opened by joel-costigliola 0
Fluent assertions for Java and Android

What is Truth? Truth makes your test assertions and failure messages more readable. Similar to AssertJ, it natively supports many JDK and Guava types,

Google 2.4k Dec 2, 2021
Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container.

Testcontainers Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium we

null 5.4k Nov 30, 2021
JVM version of Pact. Enables consumer driven contract testing, providing a mock service and DSL for the consumer project, and interaction playback and verification for the service provider project.

pact-jvm JVM implementation of the consumer driven contract library pact. From the Ruby Pact website: Define a pact between service consumers and prov

Pact Foundation 889 Nov 29, 2021
Java DSL for easy testing of REST services

Testing and validation of REST services in Java is harder than in dynamic languages such as Ruby and Groovy. REST Assured brings the simplicity of usi

REST Assured 5.6k Nov 29, 2021
Easy Setup Stub Server

Moco Moco is an easy setup stub framework. Latest Release 1.1.0 More details in Release Notes User Voice Let me know if you are using Moco. Join Moco

Zheng Ye 3.8k Dec 6, 2021
Java DSL for easy testing of REST services

Testing and validation of REST services in Java is harder than in dynamic languages such as Ruby and Groovy. REST Assured brings the simplicity of usi

REST Assured 5.6k Nov 29, 2021
Library that allows tests written in Java to follow the BDD style introduced by RSpec and Jasmine.

J8Spec J8Spec is a library that allows tests written in Java to follow the BDD style introduced by RSpec and Jasmine. More details here: j8spec.github

J8Spec 45 Apr 17, 2021
Serenity BDD is a test automation library designed to make writing automated acceptance tests easier, and more fun.

That feeling you get when you know you can trust your tests Serenity BDD is a library designed to make writing automated acceptance tests easier, and

Serenity BDD 591 Dec 2, 2021
A library for setting up Java objects as test data.

Beanmother Beanmother helps to create various objects, simple and complex, super easily with fixtures for testing. It encourages developers to write m

Jaehyun Shin 107 Oct 11, 2021
A Java architecture test library, to specify and assert architecture rules in plain Java

ArchUnit is a free, simple and extensible library for checking the architecture of your Java code. That is, ArchUnit can check dependencies between pa

TNG Technology Consulting GmbH 2k Dec 6, 2021
Roman Beskrovnyi 176 Nov 29, 2021
CodeSheriff is a simple library that helps you in writing JUnit tests that check the quality of your code

CodeSheriff is a simple library that helps you in writing JUnit tests that check the quality of your code. For example, CodeSheriff may fail because you have methods in your code that have more than X lines of code, or that have complexity greater than Y.

Maurício Aniche 61 Aug 23, 2021
Playwright is a Java library to automate Chromium, Firefox and WebKit with a single API.

Playwright is a Java library to automate Chromium, Firefox and WebKit with a single API. Playwright is built to enable cross-browser web automation that is ever-green, capable, reliable and fast.

Microsoft 382 Nov 29, 2021
🔌 Simple library to manipulate HTTP requests/responses and capture network logs made by the browser using selenium tests without using any proxies

Simple library to manipulate HTTP requests and responses, capture the network logs made by the browser using selenium tests without using any proxies

Sudharsan Selvaraj 27 Oct 23, 2021
:fire: Spring-Boot-Plus is a easy-to-use, high-speed, high-efficient,feature-rich, open source spring boot scaffolding. :rocket:

Everyone can develop projects independently, quickly and efficiently! What is spring-boot-plus? A easy-to-use, high-speed, high-efficient, feature-ric

geekidea 2.2k Nov 25, 2021
Fluent assertions library for Java

Deep Dive Assertions Deep Dive is an assertion library for Java. It offers a fluent API which allows you to dive deep, i.e. going back and forth betwe

Johannes Döbler 5 Nov 16, 2021
Java 8 optimized, memory efficient, speedy template engine producing statically typed, plain java objects

Rocker Templates by Fizzed Fizzed, Inc. (Follow on Twitter: @fizzed_inc) Sponsored by Rocker is proudly sponsored by Greenback. We love the service an

Fizzed, Inc. 639 Nov 30, 2021
jdbi is designed to provide convenient tabular data access in Java; including templated SQL, parameterized and strongly typed queries, and Streams integration

The Jdbi library provides convenient, idiomatic access to relational databases in Java. Jdbi is built on top of JDBC. If your database has a JDBC driv

null 1.6k Dec 6, 2021
Fluent assertions for Java and Android

What is Truth? Truth makes your test assertions and failure messages more readable. Similar to AssertJ, it natively supports many JDK and Guava types,

Google 2.4k Dec 2, 2021
Eclipse Collections is a collections framework for Java with optimized data structures and a rich, functional and fluent API.

English | 中文 | Deutsch | Español | Ελληνικά | Français | 日本語 | Norsk (bokmål) | Português-Brasil | Русский | हिंदी Eclipse Collections is a comprehens

Eclipse Foundation 1.8k Dec 6, 2021
Eclipse Collections is a collections framework for Java with optimized data structures and a rich, functional and fluent API.

English | 中文 | Deutsch | Español | Ελληνικά | Français | 日本語 | Norsk (bokmål) | Português-Brasil | Русский | हिंदी Eclipse Collections is a comprehens

Eclipse Foundation 1.8k Nov 29, 2021
Rich-text area for JavaFX

RichTextFX RichTextFX provides a memory-efficient text area for JavaFX that allows the developer to style ranges of text, display custom objects in-li

null 976 Dec 5, 2021
A simple configuration library for Java applications providing a node structure, a variety of formats, and tools for transformation

Configurate Configurate is a simple configuration library for Java applications that provides a node-based representation of data, able to handle a wi

SpongePowered 196 Nov 12, 2021
Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container.

Testcontainers Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium we

null 5.4k Nov 30, 2021
Z is a Java library providing accessible, consistent function combinators.

Fearless function combination in Java Techniques Unlock your functional programming potential with these combination techniques: Fusion Z.fuse(fn1, fn

J.R. 27 Nov 14, 2021
A Java library that implements a ByteChannel interface over SSLEngine, enabling easy-to-use (socket-like) TLS for Java applications.

TLS Channel TLS Channel is a library that implements a ByteChannel interface over a TLS (Transport Layer Security) connection. It delegates all crypto

Mariano Barrios 120 Nov 21, 2021
A small and easy-to-use one-time password generator library for Java according to RFC 4226 (HOTP) and RFC 6238 (TOTP).

OTP-Java A small and easy-to-use one-time password generator for Java according to RFC 4226 (HOTP) and RFC 6238 (TOTP). Table of Contents Features Ins

Bastiaan Jansen 44 Nov 21, 2021
Tink is a multi-language, cross-platform, open source library that provides cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse.

Tink A multi-language, cross-platform library that provides cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse. Ubuntu

Google 11.8k Dec 7, 2021