A programmer-oriented testing framework for Java.

Related tags

junit4
Overview
Issues
  • Release JUnit 4.13

    Release JUnit 4.13

    This issue tracks the work needed to release JUnit 4.13

    opened by kcooney 108
  • Maven project junit:junit:jar

    Maven project junit:junit:jar

    I created this artifact because we agreed we want to have the Maven build process.

    I would like to deploy this project to Maven central Snapshot repositories under version 4.11.1-SNAPSHOT, and notify the JUnit community to test. For the first looking the build outcome is useful.

    IMHO the release plan could be like this: 4.11-SNAPSHOT for #332 4.11.1-SNAPSHOT for this pull request 4.11.2-SNAPSHOT for OSGi + Maven pull request

    What you think?

    I obviously do not have server credentials user/psswd to deploy to Maven central.

    opened by Tibor17 96
  • Maven project file for JUnit as OSGi bundle

    Maven project file for JUnit as OSGi bundle

    Upon discussion #368, I created maven project file. Other e.g. maven runtime environment, and script running pom.xml may come if necessary.

    opened by Tibor17 77
  • Configurable Categories

    Configurable Categories

    Categories in suite should be multiple in annotations Categories.IncludeCategory and Categories.ExcludeCategory, and configurable by system properties as well. This pull request referst to discussions in #142 and my old pull request #354 closed by my mistake #461.

    opened by Tibor17 64
  • Junit should be an osgi bundle

    Junit should be an osgi bundle

    I sometimes use junit assertions even in production code to make sure no invalid data slips through. As some of my applications run under osgi it would be very handy if junit already was a valid osgi bundle.

    As far as I can tell it would only be necessary to switch the to packaging in the pom to bundle and add the maven bundle pllugin. I can provide a patch if that helps.

    Christian

    feature needs more info 
    opened by cschneider 62
  • Add Ordering, Orderable and @OrderWith

    Add Ordering, Orderable and @OrderWith

    These APIs allow arbitrary ordering of tests, including randomization.

    opened by kcooney 58
  • Add option for user to specify runner for parameterized tests

    Add option for user to specify runner for parameterized tests

    Test that are run with the Parameterized suite currently default to a specific runner. This change adds a @ParameterizedRunWith annotation that allows a user to specify which runner the suite should use for each Test case so the user can over-ride specific functionality within the runner.

    parameterized 
    opened by mc1arke 51
  • Upgrade to Hamcrest 1.3

    Upgrade to Hamcrest 1.3

    • Matchers in JUnitMatchers that are now provided by hamcrest-core are deprecated.
    • The static methods now delegate to CoreMatchers
    • The four Matcher classes copied from Hamcrest have been deleted.
    • Using CoreMatchers where possible

    Important: In some but not all cases, this change will cause compile errors for people using JUnitMatchers.hasItem(s), both(), and either().

    Merging this pull request would fix #36.

    opened by marcphilipp 51
  • --filter option implemented.

    --filter option implemented.

    Currently SuiteTest.suiteShouldBeOKwithNonDefaultConstructor() fails but I don't know what ought to be done about that. Under what circumstances does it make sense to have a Suite with no SuiteClasses? Suggestions?

    I'll also be refactoring out the command line processing as per @kcooney and will writing more tests for the code that has changed.

    feature 
    opened by noel-yap 47
  • Mvn test failed with TemporaryFolderUsageTest

    Mvn test failed with TemporaryFolderUsageTest

    When I test with mvn test, the error is as follows:

    Running org.junit.rules.TemporaryFolderUsageTest Tests run: 24, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.105 sec <<< FAILURE! - in org.junit.rules.TemporaryFolderUsageTest newFolderWithGivenFolderThrowsIOExceptionWhenFolderCannotBeCreated(org.junit.rules.TemporaryFolderUsageTest) Time elapsed: 0.012 sec <<< FAILURE! java.lang.AssertionError: Expected test to throw (an instance of java.io.IOException and exception with message a string containing "could not create a folder with the path 'level1'")

    test env: [email protected] [email protected] [email protected] os:centos

    opened by fubingting 1
  • Don't convert assumption failures to errors in ErrorCollector.addError()

    Don't convert assumption failures to errors in ErrorCollector.addError()

    This was previously discussed in #1363 and I think the new treatment of ErrorCollector. checkSucceeds() is correct. However ErrorCollector.addError() is more commonly used when calling sub-methods or in wrapper Rules (AOSP example) so it seems clearer (to me) to pass assumption failures through.

    #1702 is potential fix, although this has similar properties to what #1363 complained about, i.e. if addError() is used to add multiple assumption failures then they'll get re-thrown as a MultipleFailureException causing the test to fail. It seems to me that in that case the test probably needs restructuring anyway (e.g. to check its assumptions before calling multiple sub-methods), but I'm open to opinions.

    opened by prbprbprb 0
  • Don't convert assumption failures to errors in ErrorCollector.addErro…

    Don't convert assumption failures to errors in ErrorCollector.addErro…

    …r().

    Provides clearer results when calling sub-methods or when wrapping tests via a Rule.

    opened by prbprbprb 0
  • OrderWith in parameterized tests

    OrderWith in parameterized tests

    The ordering introduced with #1130 is a great feature. Also the fact that the annotation is inherited is really helpful in some cases.

    But when a parameterized test inherits an OrderWith annotation, its parameters get reordered as well. Another case where this behaviour could be a problem would be a parameterized test with more than one test method, where you add an OrderWith annotation in order to sort the test methods but not the parameters.

    As long as the parameters name value starts with "{index}" and the amount of parameters is <10 there is no problem, because the order remains the same (at least with the provided alphanumeric ordering). If there are >10 parameters, the alphabetical order is 1, 10, 11, 2, 3, ...

    I could think of the following possibilites to solve this:

    • OrderWith should only sort test methods - not parameters. You have enough control over the parameter order in the parameters method and that order should not get changed.
    • Add leading zeros to the {index} placeholder value or add an additional placeholder that outputs the index with leading zeros.
    • Add an ordering to use with the OrderWith annotation using the org.junit.runner.manipulation.Sorter.NULL sorter to be able to override an inherited ordering (only solves case 1)
    parameterized 
    opened by phoenix384 0
  • Build failure with OpenJDK 17

    Build failure with OpenJDK 17

    There is a build failure with OpenJDK 17 caused by javadoc errors:

    [INFO] -------------------------------------------------------------
    [ERROR] COMPILATION ERROR :
    [INFO] -------------------------------------------------------------
    [ERROR] /<<PKGBUILDDIR>>/src/main/java/org/junit/runners/Parameterized.java:[125,3] error: heading used out of sequence: <H3>, compared to implicit preceding heading: <H1>
    [ERROR] /<<PKGBUILDDIR>>/src/main/java/org/junit/Test.java:[31,3] error: heading used out of sequence: <H3>, compared to implicit preceding heading: <H1>
    [ERROR] /<<PKGBUILDDIR>>/src/main/java/org/junit/ClassRule.java:[34,3] error: heading used out of sequence: <H3>, compared to implicit preceding heading: <H1>
    [ERROR] /<<PKGBUILDDIR>>/src/main/java/org/junit/rules/ExpectedException.java:[19,3] error: heading used out of sequence: <H3>, compared to implicit preceding heading: <H1>
    [ERROR] /<<PKGBUILDDIR>>/src/main/java/org/junit/Rule.java:[26,3] error: heading used out of sequence: <H3>, compared to implicit preceding heading: <H1>
    [INFO] 5 errors
    
    javadoc maven 
    opened by ebourg 3
  • Consider declaring class for Enclosed tests in  Categories

    Consider declaring class for Enclosed tests in Categories

    At QueryDSL, we were surprised that Enclosed tests were not run when the category was included as group filter.

    It turns out to be because the declaring class is not considered when determining the categories for a particular test. This pull request changes that behaviour to also consider the declaring class.

    Example:

    @Category(H2.class)
    public class H2LiteralsSuiteTest extends AbstractSuite {
    
        public static class BeanPopulation extends BeanPopulationBase { }
        public static class Delete extends DeleteBase { }
        public static class Insert extends InsertBase { }
        public static class KeywordQuoting extends KeywordQuotingBase { }
        public static class LikeEscape extends LikeEscapeBase { }
    

    Where AbstractSuite is annotated with @RunWith(Enclosed.class).

    When <groups>com.querydsl.core.testutil.H2</groups> is used, none of the inner test classes is executed, unless they themselves are annotated with @Category(H2.class). To us it would make sense that this is implicit.

    Source: https://github.com/querydsl/querydsl/blob/master/querydsl-sql/src/test/java/com/querydsl/sql/suites/H2LiteralsSuiteTest.java#L9-L16

    opened by jwgmeligmeyling 0
  • Theories: only get all data points from enum and boolean types if the…

    Theories: only get all data points from enum and boolean types if the…

    …re is no @FromDataPoints annotation, or the named data points represent a non-empty set of the same type.

    Fixes #1648

    changes requested 
    opened by awturner 3
  • `@FromDataPoints(

    `@FromDataPoints("misspelled") EnumType` shouldn't test all enum values

    @RunWith(Theories.class)
    public class NonExistentTheory {
      @DataPoints("foo")
      public static final ImmutableSet<MetaSyntacticVariable> FOOS =
          ImmutableSet.of(MetaSyntacticVariable.FOO);
    
      @Theory
      public void doWithTheFoo(@FromDataPoints("bar") MetaSyntacticVariable whatever) {
        System.err.println(whatever);
      }
    
      @Theory
      public void doWithTheBoolean(@FromDataPoints("bar") boolean whatever) {
        System.err.println(whatever);
      }
    
      enum MetaSyntacticVariable {
        FOO, BAR, BAZ
      }
    }
    

    It is surprising that these @FromDataPoints-annotated parameters receive the same values as if the annotation were omitted. This means that typos in data point names aren't flagged as errors.

    If the @FromDataPoints is present, and nothing matches, it would be helpful to raise "Never found parameters that satisfied method assumptions.".

    bug theories 
    opened by awturner 2
  • Made some variable names more consistent with the other parts.

    Made some variable names more consistent with the other parts.

    Hello, we're developing an automated system that detects inconsistent variable names in a large software project. Our system checks if each variable name is consistent with other variables in the project in its usage pattern, and proposes correct candidates if inconsistency is detected. This is a part of academic research that we hope to publish soon, but as a part of the evaluation, we applied our systems to your projects and got a few interesting results. We carefully reviewed our system output and manually created a patch to correct a few variable names. We would be delighted if this patch is found to be useful. If you have a question or suggestion regarding this patch, we'd happily answer. Thank you.

    P.S. our patch is purely for readability purposes and does not change any functionality. A couple of issues that we've noticed were left untouched. For example, mixed use of variable names "msg" and "message" were fairly widespread, but we have only corrected a few notable instances to minimize our impact.

    opened by euske 0
Releases(r4.13.2)
Owner
JUnit
A programmer-oriented testing framework for Java.
JUnit
Layout and functional testing framework for websites

Galen Framework master: Galen is an open-source tool for testing layout and responsive design of web applications. It is also a powerfull functional t

Galen Framework 1.4k Mar 5, 2021
The Enterprise-ready testing and specification framework.

Spock Framework Spock is a BDD-style developer testing and specification framework for Java and Groovy applications. To learn more about Spock, visit

Spock Framework 2.8k Mar 14, 2021
A programmer-oriented testing framework for Java.

JUnit 4 JUnit is a simple framework to write repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks. For more infor

JUnit 8.1k Apr 29, 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 831 Mar 13, 2021
A simple yet powerful parameterized test runner for Java.

TestParameterInjector Introduction TestParameterInjector is a JUnit4 test runner that runs its test methods for different combinations of field/parame

Google 44 Apr 6, 2021
Java binding for Hoverfly

Hoverfly Java - Easy Creation of Stub Http Servers for Testing A Java native language binding for Hoverfly, a Go proxy which allows you to simulate ht

null 130 Feb 7, 2021
Clojure bindings for the Chromium Embedded Framework

clj-cef Clojure bindings for the Chromium Embedded Framework Dependency: Rationale From https://bitbucket.org/chromiumembedded/cef/src/master/ Some us

Adrian 30 Mar 25, 2021
Captures log entries for unit testing purposes

LogCaptor Install with maven <dependency> <groupId>io.github.hakky54</groupId> <artifactId>logcaptor</artifactId> <version>2.4.0</version>

null 55 Mar 11, 2021
PowerMock is a Java framework that allows you to unit test code normally regarded as untestable.

Writing unit tests can be hard and sometimes good design has to be sacrificed for the sole purpose of testability. Often testability corresponds to go

PowerMock 3.4k Mar 13, 2021
PowerMock is a Java framework that allows you to unit test code normally regarded as untestable.

Writing unit tests can be hard and sometimes good design has to be sacrificed for the sole purpose of testability. Often testability corresponds to go

PowerMock 3.4k Mar 15, 2021
Enabling Test Automation in Java

SeLion Enabling Test Automation in Java SeLion builds on top of TestNG and Selenium to provide a set of capabilities that get you up and running with

PayPal 252 Feb 2, 2021
AssertJ is a library providing easy to use rich typed assertions

AssertJ - Fluent assertions for java AssertJ provides a rich and intuitive set of strongly-typed assertions to use for unit testing (with JUnit, TestN

AssertJ 1.9k Mar 14, 2021
FitNesse -- The Acceptance Test Wiki

FitNesse Welcome to FitNesse, the fully integrated stand-alone acceptance testing framework and wiki. To get started, check out http://fitnesse.org! Q

Robert C. Martin 1.6k Mar 14, 2021
Lightweight analysis tool for detecting mutability in Java classes

What is Mutability Detector? Mutability Detector is designed to analyse Java classes and report on whether instances of a given class are immutable. I

Mutability Detector 218 Mar 1, 2021