Skip to content

Latest commit

 

History

History
38 lines (27 loc) · 3.02 KB

CONTRIBUTING.md

File metadata and controls

38 lines (27 loc) · 3.02 KB
Raw

Contributing

You discovered a bug or have an idea for a new feature? Great, why don't you send me a Pull Request (PR) so everyone can benefit from it?

Getting started is easy:

  • Fork the java-object-diff repository on Github
  • Clone the forked repository to your computer
  • Switch to the root project directory and run mvn clean package

If everything went well, this should build, test and package the project. Now you can start making your changes.

There are some things to help you getting started:

  • Make yourself familiar with the User Guide, so you understand the basic architecture.
  • Check for open issues that interest you or look for issues with the Contributor Friendly tag. These issues are especially well suited to get more familiar with the codebase without being overwhelming.
  • In case you have an idea for a new feature, check the issue tracker to see if there were already some discussions regarding that feature. If not, feel free to open a new discussion to see what others think about it.

So you found something you want to work on? That's great! If you run into any problems or are not entirely sure how to tackle the problem, feel free to ask me on Twitter or post your question to the issue tracker if it is more complex.

Before you submit your PR with the result, please make sure to:

  • Write at least one fully integrated test (no mocks and comparison done via public API) to show that the fix or feature works as promised - from a user perspective. What you are doing here is basically saying: "In case of X you can expect the library to behave like Y". You shouldn't cover every possible execution path this way but rather focus on proving that the feature works and under which circumstances it will take effect. Doing this will help others to keep your feature intact, when the library evolves.
  • Write unit tests! Lots of them! Keep them small and readable and try to cover as much of your logic as possible. But don't go overboard: focus on actual logic and avoid testing simple getters and setters just to reach the magical 100% test coverage.
  • Write your tests with Groovy and Spock! Spock is an amazing testing framework that makes many things much, much easier to accomplish. It's not hard to learn and a lot of fun to use. Yes, I know that there are still some TestNG tests in the codebase, but they are getting replaced one by one until the dependency can finally be removed.

When you've done that, nothing should hold you back from sending me a pull request and bug me until it gets merged and published. 😉

Thanks for your support and happy coding!