TODO update this for Open Source developers PLFM-194

Notes on best practices.  This is a work in progress and suggested guidelines, not a rulebook to follow like slaves.

Testing

If it isn't tested, it doesn't work.  Period.  All new features require appropriate unit tests and integration tests as part of the development process.  Passing tests should be checked in the same time as new code, and are fully in the scope of code reviews.

We use JUnit as a testing framework and Mockito for testing, mocking, stubbing etc. At the time of writing we use both JUnit5 and JUnit4 for backward compatibility and we are trying to move into the direction of JUnit5 for all new tests. In order to incrementally update the code base without having disrupting PRs we adopt the following simple rules:

To upgrade a test from JUnit4 to JUnit5 in general the following steps might be necessary:

Code Reviews

Let's do code reviews for all code changes.

Regarding rigor, I don't expect the reviewer to scrutinize the code (the burden is on me to test it) but instead to:

  1. get the gist of what I'm trying to do or let me know if its confusing (because I haven't done a decent job if the code change is confusing)
  2. let me know whether the approach I've taken seems reasonable or if there is a better way to do it
  3. give me a clue if the way I am testing it is missing major important cases
  4. point out any dependencies of which I might be unaware (e.g., if I change the REST API in a particular way, who might that change impactand is that okay?)

Meetings

Driving considerations

Meeting Schedule