A programmer-oriented testing framework for Java.

Related tags

Testing junit4
Overview
Comments
  • 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
  • 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 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
  • #727 Fail on timeout displays stack of stuck thread

    #727 Fail on timeout displays stack of stuck thread

    New class: ExceptionWithThread.java (subclass of Exception that keeps information about some other relevant thread). Changed: FailOnTimeout.java (starts test in a new ThreadGroup; on timeout, looks at running threads in ThreadGroup to see which one it thinks got stuck, creates an ExceptionWithThread if it finds one); Failure.java (displays stack for the "relevant thread" if it handles an ExceptionWithThread)

    opened by adam-beneschan 44
  • Improvement: Concurrent Queue in RunNotifier instead of Old Synchronized ArrayList

    Improvement: Concurrent Queue in RunNotifier instead of Old Synchronized ArrayList

    The old RunNotifier uses synchronized ArrayList in Listeners.

    Without the synchronization the concurrently modified Listeners throw ConcurrentModificationException on iterator.

    This synchronization is no longer needed with ConcurrentLinkedQueue because it is already thread safe and non-blocking.

    This change will speed up tests because of not having any locks.

    opened by Tibor17 43
  • Parameterized runner should name tests better than sequential numbers

    Parameterized runner should name tests better than sequential numbers

    Right now the test names are named sequentially 0,1, etc in Parameterized:

    @Override protected String getName() { return String.format("[%s]", fParameterSetNumber); }

    @Override protected String testName(final Method method) { return String.format("%s[%s]", method.getName(), fParameterSetNumber); }

    It would help if the data themselves were to be used in determining the name. Proposed alternatives for name (which has to be determinited statically before Test is instantiated):

    • call toString on first parameter
    • call the a newly added names attribute to Parameters annotation (with default empty names for compatibility) public String[] names() default {};
    • call a public, static (!) method annotated by newly-defined @TestName and accepting the same arguments as the constructor

    I can provide (again) a patch. This issue was tracked as http://sourceforge.net/tracker/?func=detail&atid=365278&aid=1742040&group_id=15278 and https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1630834&group_id=15278 I can submit a patch if needed

    feature parameterized 
    opened by anshnd 42
  • Flexible ParallelComputer

    Flexible ParallelComputer

    The ParallelComputer with unlimited Thread pool size is not enugh.

    Thus I added methods with parameters where the user can change the Thread pool as he likes.

    Opened discussion #518 and got the consensus to update ParallelComputer.

    methods(ExecutorService) classes(ExecutorService) classesAndMethodsUnbounded() classesAndMethodsBounded(int nThreads) classesAndMethods(ThreadPoolExecutor) classesAndMethods(ThreadPoolExecutor pool, int minConcurrentMethods) classesAndMethods(ExecutorService poolClasses, ExecutorService poolMethods)

    opened by Tibor17 41
  • junit-dep not uploaded to Maven repository since 4.5

    junit-dep not uploaded to Maven repository since 4.5

    I see versions 4.6 and 4.7 of the bundled-libraries version of JUnit in the Maven Central repo, but no junit-dep. Can this be added by whoever is doing the uploads?

    bug regression 
    opened by MichaelHackett 41
  • [SECURITY] Fix Temporary Directory Hijacking or Information Disclosure Vulnerability

    [SECURITY] Fix Temporary Directory Hijacking or Information Disclosure Vulnerability

    Security Vulnerability Fix

    This pull request fixes either 1.) Temporary Directory Hijacking Vulnerability, or 2.) Temporary Directory Information Disclosure Vulnerability, which existed in this project.

    Preamble

    The system temporary directory is shared between all users on most unix-like systems (not MacOS, or Windows). Thus, code interacting with the system temporary directory must be careful about file interactions in this directory, and must ensure that the correct file permissions are set.

    This PR was generated because the following chain of calls was detected in this repository in a way that leaves this project vulnerable. File.createTempFile(..) -> file.delete() -> either file.mkdir() or file.mkdirs().

    Impact

    This vulnerability can have one of two impacts depending upon which vulnerability it is.

    1. Temporary Directory Information Disclosure - Information in this directory is visable to other local users, allowing a malicious actor co-resident on the same machine to view potentially sensitive files.
    2. Temporary Directory Hijacking Vulnerability - Same impact as 1. above, but also, ther local users can manipulate/add contents to this directory. If code is being executed out of this temporary directory, it can lead to local priviledge escalation.

    Temporary Directory Hijacking

    This vulnerability exists because the return value from file.mkdir() or file.mkdirs() is not checked to determine if the call succeeded. Say, for example, because another local user created the directory before this process.

    File tmpDir = File.createTempFile("temp", ".dir"); // Attacker knows the full path of the directory that will be later created
    // delete the file that was created
    tmpDir.delete(); // Attacker sees file is deleted and begins a race to create their own directory before the java code.
    // and makes a directory of the same name
    // SECURITY VULNERABILITY: Race Condition! - Attacker beats java code and now owns this directory
    tmpDir.mkdirs(); // This method returns 'false' because it was unable to create the directory. No exception is thrown.
    // Attacker can write any new files to this directory that they wish.
    // Attacker can read any files created within this directory.
    

    Other Examples

    Temporary Directory Information Disclosure

    This vulnerability exists because, although the return values of file.mkdir() or file.mkdirs() are correctly checked, the permissions of the directory that is created follows the default system uname settings. Thus, the directory is created with everyone-readable permissions. As such, any files/directories written into this directory are viewable by all other local users on the system.

    File tmpDir = File.createTempFile("temp", ".dir");
    tmpDir.delete();
    if (!tmpDir.mkdirs()) { // Guard correctly prevents temporary directory hijacking, but directory contents are everyone-readable.
        throw new IOException("Failed to create temporary directory");
    }
    

    Other Examples

    The Fix

    The fix has been to convert the logic above to use the following API that was introduced in Java 1.7.

    File tmpDir = Files.createTempDirectory("temp dir").toFile();
    

    The API both created the directory securely, ie with a random, non-conflicting name, with directory permissions that only allow the currently executing user to read or write the contents of this directory.

    :arrow_right: Vulnerability Disclosure :arrow_left:

    :wave: Vulnerability disclosure is a super important part of the vulnerability handling process and should not be skipped! This may be completely new to you, and that's okay, I'm here to assist!

    First question, do we need to perform vulnerability disclosure? It depends!

    1. Is the vulnerable code only in tests or example code? No disclosure required!
    2. Is the vulnerable code in code shipped to your end users? Vulnerability disclosure is probably required!

    Vulnerability Disclosure How-To

    You have a few options options to perform vulnerability disclosure. However, I'd like to suggest the following 2 options:

    1. Request a CVE number from GitHub by creating a repository-level GitHub Security Advisory. This has the advantage that, if you provide sufficient information, GitHub will automatically generate Dependabot alerts for your downstream consumers, resolving this vulnerability more quickly.
    2. Reach out to the team at Snyk to assist with CVE issuance. They can be reached at the Snyk's Disclosure Email.

    Detecting this and Future Vulnerabilities

    This vulnerability was automatically detected by GitHub's LGTM.com using this CodeQL Query.

    You can automatically detect future vulnerabilities like this by enabling the free (for open-source) GitHub Action.

    I'm not an employee of GitHub, I'm simply an open-source security researcher.

    Source

    This contribution was automatically generated with an OpenRewrite refactoring recipe, which was lovingly hand crafted to bring this security fix to your repository.

    The source code that generated this PR can be found here: UseFilesCreateTempDirectory

    Opting-Out

    If you'd like to opt-out of future automated security vulnerability fixes like this, please consider adding a file called .github/GH-ROBOTS.txt to your repository with the line:

    User-agent: JLLeitschuh/security-research
    Disallow: *
    

    This bot will respect the ROBOTS.txt format for future contributions.

    Alternatively, if this project is no longer actively maintained, consider archiving the repository.

    CLA Requirements

    This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.

    It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed-off.

    The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see https://developercertificate.org/ for more information).

    - Git Commit Signoff documentation

    If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.

    Sponsorship & Support

    This contribution is sponsored by HUMAN Security Inc. and the new Dan Kaminsky Fellowship, a fellowship created to celebrate Dan's memory and legacy by funding open-source work that makes the world a better (and more secure) place.

    This PR was generated by Moderne, a free-for-open source SaaS offering that uses format-preserving AST transformations to fix bugs, standardize code style, apply best practices, migrate library versions, and fix common security vulnerabilities at scale.

    Tracking

    All PR's generated as part of this fix are tracked here: https://github.com/JLLeitschuh/security-research/issues/10

    opened by JLLeitschuh 0
  • Compilation error in org.junit.runner.Result - ObjectInputStream.GetField.get(name, object) throws ClassNotFoundException

    Compilation error in org.junit.runner.Result - ObjectInputStream.GetField.get(name, object) throws ClassNotFoundException

    This code fails to compile on JDK 18 and newer:

    https://github.com/junit-team/junit4/blob/cc7c500584fcb85eaf98c568b7441ceac6dd335c/src/main/java/org/junit/runner/Result.java#L190-L198

    src/main/java/org/junit/runner/Result.java:192: error: unreported exception ClassNotFoundException; must be caught or declared to be thrown
                fCount = (AtomicInteger) fields.get("fCount", null);
                                                   ^
    src/main/java/org/junit/runner/Result.java:193: error: unreported exception ClassNotFoundException; must be caught or declared to be thrown
                fIgnoreCount = (AtomicInteger) fields.get("fIgnoreCount", null);
                                                         ^
    src/main/java/org/junit/runner/Result.java:194: error: unreported exception ClassNotFoundException; must be caught or declared to be thrown
                assumptionFailureCount = (AtomicInteger) fields.get("assumptionFailureCount", null);
                                                                   ^
    src/main/java/org/junit/runner/Result.java:195: error: unreported exception ClassNotFoundException; must be caught or declared to be thrown
                fFailures = (List<Failure>) fields.get("fFailures", null);
                                                      ^
    

    This is the corresponding JDK change: https://bugs.openjdk.java.net/browse/JDK-8276742

    opened by cushon 0
  • Possibility to specify suite classes in custom Categories subclasses constructor

    Possibility to specify suite classes in custom Categories subclasses constructor

    If subclassing the Suite class one can implement a constructor which can invoke a custom static method to specify test suite classes. This is currently not possible with subclasses ob Categories.

    Therefore i propose this small fix to expose the constructor with the signature Categories(RunnerBuilder, Class, Class[]) to subclasses.

    opened by dbratusa 0
  • @Rule execution order looks to have been guaranteed since 4.12 but is not documented as such

    @Rule execution order looks to have been guaranteed since 4.12 but is not documented as such

    My understanding is that https://github.com/junit-team/junit4/commit/c75dcc28810aeb1c918ee7430981b31f41742ea7#diff-f35409420f2540415a9878beaf5a537248f301b6c683bb87a11016be3c9dc8b8R55 caused JUnit to begin processing @Rule fields in a defined order. The @Rule Javadoc, however, still states that the order is defined by the JVM's reflection API.

    It would be good to know whether the intent is to commit to this order or not. I suppose that the current doc is technically wrong either way, since the current order is not dependent on the JVM reflection API :) But mainly I want to know how safe this is to rely on. Thanks.

    (Sorry if I missed some past discussion in my searching or if I've misunderstood something.)

    opened by cpovirk 1
Releases(r4.13.2)
Owner
JUnit
A programmer-oriented testing framework for Java.
JUnit
Powerful, elegant and flexible test framework for Kotlin with additional assertions, property testing and data driven testing

Kotest is a flexible and comprehensive testing tool for Kotlin with multiplatform support. To learn more about Kotest, visit kotest.io or see our quic

Kotest 3.6k Sep 26, 2022
Android Unit Testing Framework

Robolectric is the industry-standard unit testing framework for Android. With Robolectric, your tests run in a simulated Android environment inside a

Robolectric 5.5k Sep 27, 2022
Morsa: Jetpack Compose UI Testing Framework

Morsa: Jetpack Compose UI Testing Framework Test library to ease UI testing with Jetpack Compose Purpose This library aims to add some useful wrappers

HyperDevs 8 Sep 22, 2022
Snapshot Testing framework for Kotlin.

KotlinSnapshot Snapshot Testing framework for Kotlin. What is this? Snapshot testing is an assertion strategy based on the comparision of the instance

Pedro Gómez 154 Jul 2, 2022
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.9k Sep 28, 2022
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.9k Sep 28, 2022
Most popular Mocking framework for unit tests written in Java

Most popular mocking framework for Java Current version is 3.x Still on Mockito 1.x? See what's new in Mockito 2! Mockito 3 does not introduce any bre

mockito 13.3k Sep 28, 2022
Android UI Testing

User scenario testing for Android Robotium is an Android test automation framework that has full support for native and hybrid applications. Robotium

null 2.8k Sep 13, 2022
A set of AssertJ helpers geared toward testing Android.

AssertJ Android A set of AssertJ assertions geared toward testing Android. Deprecated The support libraries and play services are developing at a rate

Square 1.6k Sep 29, 2022
Android UI Testing

User scenario testing for Android Robotium is an Android test automation framework that has full support for native and hybrid applications. Robotium

null 2.7k Apr 8, 2021
A sample repo describing best practices for snapshot testing on Android

Road to effective snapshot testing A sample repo describing best practices for snapshot testing on Android. This includes for now: Parameterized Tests

Sergio Sastre Flórez 44 Sep 12, 2022
Turbine is a small testing library for kotlinx.coroutines Flow.

A small testing library for kotlinx.coroutines Flow

Cash App 1.7k Oct 2, 2022
Fixtures for Kotlin providing generated values for unit testing

A tool to generate well-defined, but essentially random, input following the idea of constrained non-determinism.

Appmattus Limited 175 Sep 28, 2022
Lovely Systems Database Testing

Lovely DB Testing This repository provides opinionated testing helpers for database testing used at Lovely Systems. License This plugin is made availa

Lovely Systems GmbH 1 Feb 23, 2022
Project for testing intern candidate simple level

RickAndMorty-TestTask Тестовый проект 'Гайд по мультфильму Рик и Морти' для практикантов начального и продвинутого уровня. Структура проекта Структура

null 0 Nov 18, 2021
Very simple Morse API text translator. Mainly to do some testing with jitpack, API development etc.

Very simple Morse text translator API. Far from finish or even being reliable. Use for single sentence. Mainly to test github dependency for Android

Piotr Dymala 0 Dec 30, 2021
A set of TestRules and ActivityScenarios to facilitate UI Testing under given configurations: FontSizes, Locales

AndroidUiTestingUtils A set of TestRules, ActivityScenarios and utils to facilit

Sergio Sastre Flórez 96 Oct 1, 2022
Testify — Android Screenshot Testing

Testify — Android Screenshot Testing Add screenshots to your Android tests Expand your test coverage by including the View-layer. Testify allows you t

ndtp 28 Aug 23, 2022
A powerful test framework for Android

Cafe A powerful test framework for Android named Case Automated Framework for Everyone. Home Page http://baiduqa.github.com/Cafe/ How to make Cafe dow

Baidu 368 Jun 10, 2022