CONTRIBUTING.md

Contributing

When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.

Please note we have a code of conduct, please follow it in all your interactions with the project.

Code Standards

General

1. Do not use field injection (ie. @Value, @Autowired)
   • Instead use an @Autowired or @Value annotated constructor
   • Provide a static builder (ie. Lombok @Builder annotation)
   • This helps to improves testability
   • Helps to decouple from Spring
   • If your constructor is feeling messy or too big - you are probably overloading the class you are working on
2. Do not use any implementation specific JPA code (ie. Hibernate-only annotations)
   • Exception for when no alternative functionality exists (ie. Postgres JSON field search)
3. All of our code is auto-formatted to Google Java Format using the fmt-maven-plugin on build:

<plugin>
    <groupId>com.coveo</groupId>
    <artifactId>fmt-maven-plugin</artifactId>
    <version>${FMT_MVN_PLG.VERSION}</version>
    <executions>
        <execution>
            <goals>
                <goal>format</goal>
            </goals>
        </execution>
    </executions>
</plugin>

5. Constants

• must be declared in a @NoArgsConstructor(access=PRIVATE) annotated class with a name representative of the type of constants. For example, the class Tables under the package constants would contain sql table names.
• Constant variable names should be consistent throughout code base. For example, the text egoUserPermissions should be defined by the variable EGO_USER_PERMISSION.

6. If a method is not stateful and not an interface/abstract method, then it should be static
7. Never allow a method to return null. Instead, it should return Optiona<T> or an empty container type (something that has .isEmpty())

Service Layer

1. Get * should always return Optional
2. Find * should always return a Collection

JPA

1. Entity member declarations should take the following presidence:
   1. @Id (identifier)
   2. Non-relationship @Column
   3. @OneToOne
   4. @OneToMany
   5. @ManyToOne
   6. @ManyToMany
2. As explained in this article, you should prefer bidirectional associations since they are more efficient than unidirectional ones in terms of SQL performance source
3. Always lazy load for @OneToMany and @ManyToMany
4. Never use CascadeType.ALL or CascadeType.REMOVE becuase they are too destructive. Use CascadeType.MERGE and CascadeType.PERSIST instead
5. Name methods with remove indicating an entity was deleted
6. Name methods with dissociate indicating a child relationship with its parent will be destoryed
7. For performance reasons, @ManyToMany collections should be a Set as described here
8. For performance reasons, @OneToMany collections should be a list as described here
9. In ManyToMany relationships, the JoinTable should only be defined on the owning side , and on the inverse side the mappedBy ManyToMany annotation parameter should be defined, as described here

Testing

1. Test FEATURES not methods
2. Test method names should follow this convention: [the name of the tested feature]_[expected input / tested state]_[expected behavior].

General

1. DB via Test Containers - no in-memory DB or OS specific services
2. No dependencies on any external services (ie. production micro-service)
3. Tests DO NOT clear their data between runs, meaning that no test should rely on or expect a clean DB when running

Unit Testing

Integration Testing