Skip to content

Files

Latest commit

marcphilippmarcphilipp
Add DoD to contribution guidelines (junit-team#593)
Feb 14, 2017
611d66d · Feb 14, 2017

History

History
91 lines (65 loc) · 3.55 KB

CONTRIBUTING.md

File metadata and controls

91 lines (65 loc) · 3.55 KB

Contributing

JUnit Contributor License Agreement

  • You will only Submit Contributions where You have authored 100% of the content.
  • You will only Submit Contributions to which You have the necessary rights. This means that if You are employed You have received the necessary permissions from Your employer to make the Contributions.
  • Whatever content You Contribute will be provided under the Project License(s).

Project Licenses

Commit Messages

As a general rule, the style and formatting of commit messages should follow the guidelines in How to Write a Git Commit Message.

Pull Requests

Our Definition of Done offers some guidelines on what we expect from a pull request. Feel free to open a pull request that does not fulfill all criteria, e.g. to discuss a certain change before polishing it, but please be aware that we will only merge it in case the DoD is met.

Please add the following lines to your pull request description:

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

Coding Conventions

Formatting

Code formatting is enforced using the Spotless Gradle plugin. You can use gradle spotlessApply to format new code and add missing license headers to source files. Formatter and import order settings for Eclipse are available in the repository under src/eclipse/junit-eclipse-formatter-settings.xml and src/eclipse/junit-eclipse.importorder, respectively. For IntelliJ IDEA there's a plugin you can use in conjunction with the Eclipse settings.

Text in *.adoc and *.md files should be wrapped at 90 characters whenever technically possible.

Javadoc

  • Javadoc comments should be wrapped after 80 characters whenever possible.
  • This first paragraph must be a single, concise sentence that ends with a period (".").
  • Place <p> on the same line as the first line in a new paragraph and precede <p> with a blank line.
  • Insert a blank line before at-clauses/tags.
  • Favor {@code foo} over <code>foo</code>.
  • Favor literals (e.g., {@literal @}) over HTML entities.
  • Use @since 5.0 instead of @since 5.0.0.
  • Do not use @authortags. Instead, contributors will be listed on the website and in release notes.

Tests

Naming

  • All test classes must end with a Tests suffix.
  • Example test classes that should not be picked up by the build must end with a TestCase suffix.

Assertions

  • Use org.junit.jupiter.api.Assertions wherever possible.
  • Use AssertJ when richer assertions are needed.
  • Do not use org.junit.Assert or junit.framework.Assert.

Mocking

  • Use either Mockito or hand-written test doubles.

Logging

  • Use sparingly
  • Do not log in utility classes (junit-platform-commons)
  • Levels
    • SEVERE (Log4J: ERROR): extra information (in addition to an Exception) about errors that will halt execution
    • WARNING (Log4J: WARN): potential usage errors that should not halt execution
    • INFO: stuff the users might want to know but not by default (Example: ServiceLoaderTestEngineRegistry logs IDs of discovered engines)
    • FINE (Log4J: DEBUG)
    • FINER (Log4J: TRACE)