This repository contains a sample Java integration between:
- Operto: A Canada-based property management system focused on cleaning and smart access
- BrightSide Rental Management Software: A platform for tracking, upkeep, and billing in the short-term rental industry
Note: This codebase is an educational sample—not a working production integration. It illustrates design patterns and techniques commonly used in professional Java backend projects.
- The primary focus is the
OpertoApiclass, which manages retrieval and synchronization of data between the two systems. - The
referencepackage provides placeholder/domain objects relevant to the scenario. - The project demonstrates integrating new logic into a legacy codebase, where many dependencies are highly coupled and lack test coverage. To address this, the code uses DTOs (a GWT requirement) and several deprecated libraries.
- The
OpertoApiTestclass uses TDD techniques with custom mock objects and spies, avoiding external dependencies. - HTTP calls are managed via the OkHttp3 library, with an
OkHttpWrapperto aid logging and reduce duplication.
This project illustrates key aspects of Test-Driven Development (TDD):
- Tests First: Features and integration logic are designed by first writing tests that specify the desired behavior before implementing production code.
- Mocking and Spies: Unit tests use custom mocks and spies to simulate dependencies and external services, ensuring tests are fast, isolated, and reproducible. This avoids reliance on real HTTP calls or external systems.
- Refactoring with Confidence: With comprehensive tests in place, the codebase can be refactored or extended safely, as tests quickly reveal regressions or unexpected behavior.
Benefits demonstrated:
- Promotes clearly defined and testable interfaces.
- Encourages loose coupling and modular architecture.
- Ensures robust test coverage and reliable future maintenance.
For examples, see
OpertoApiTestand the usage of custom mocks and spies for model and HTTP interactions.
This sample intentionally demonstrates implementation of the SOLID principles:
-
Single Responsibility Principle:
Methods and classes are designed to handle one aspect of data integration at a time. -
Open/Closed Principle:
Usage of aModelRegistryenables injecting and expanding models without modifying existing logic, supporting extension over modification. -
Liskov Substitution Principle:
All code is written against abstract types, allowing mock and spy objects to substitute for real models seamlessly in tests. -
Interface Segregation Principle:
Interfaces are minimized; for instance, separateLoadableandSaveableinterfaces mean implementers only include the operations they need. This is visible in both model and test code. -
Dependency Inversion Principle:
High-level code (such asOpertoApi) depends on abstractions supplied by the registry, not concrete model implementations. This enables simple swapping for mocks/spies during tests and future flexibility.
- Extensibility:
You can add new integrations, models, or test cases following the patterns established here with minimal code changes.
Feel free to use or adapt this adjustment based on your audience. If you'd like a sample “How to Run the Tests” or general “How to Extend” section, let me know!