Skip to content

CLAUDE.md

Latest commit

 

History

History
72 lines (55 loc) · 2.93 KB

CLAUDE.md

File metadata and controls

72 lines (55 loc) · 2.93 KB

Testing

  • Run ./gradlew test to run unit tests
  • Run ./gradlew intTest to run integration tests
  • Tests use kotest for assertions

Running

  • Main class: com.cdpjenkins.genetic.evolver.EvolverMain
  • Run with ./gradlew run or run the main class directly

Architecture

  • Uses ports and adapters architecture
  • Handlers deal with HTTP requests or event logic, not business logic
  • Commands handle business logic and should not directly access the database

Persistence

  • DudeStore: Remote persistence for individuals and settings
  • S3: Optional persistence controlled by EvolverSettings.saveToS3
  • Filesystem: Optional persistence controlled by EvolverSettings.saveToFilesystem
  • FilePersister writes to output/ directory every 10 generations

General

  • ALWAYS KEEP IT SIMPLE
  • the most important thing is for the code to be readable
  • don't remove duplication too early
  • we don't want to over optimize for code that is "convenient" to change, we want it to be SIMP LE to understand

Debugging

  • when tests fail tell me the specific error message
  • don't guess why tests are failing, be methodical when debugging
    • increase the observerability of the code to understand where the problem is
    • figure out a what point in the process steps that the behvaiour is not as expected
  • keep a track of the number of times you have tried to fix the same problem
  • when you have tried 3 times to fix the same problem, then ALWAYS stop and ask me for help

Comments

  • NEVER ADD COMMENTS
  • ALWAYS secondard step after generating any code, to see if any comment were add, and remove them
  • instead of adding comments, think about how to name variables and functions that don't need comments

Process

  • ALWAYS use TDD to implement changes

Step 1. write a failing test Step 2. check that the failing test gives the expected error message Step 3. pass the test in the simplest way possible, and triangulate onto the solution Step 4. check if the implementation needs any refactoring

  • when in the failing test stage, output a message to say: We are RED ❌ : <error_message> <is_this_error_expected> 'We were expecting this error' OR 'We were NOT expecting this error'

  • after checking that the test are passing, output a message to say: We are GREEN ✅ : <number_of_tests_passed> / <number_of_tests>

  • when in the refactoring stage, ouput a message to say REFACTORING 🛠️ : <refactoring_description>

  • After every refactoring step, ALWAYS immediately run tests to verify the changes preserve existing behavior. NEVER consider a refactoring complete until all tests pass.

  • prefer outside-in testing to keep the code easier to refactor later

Commits

  • Write commit messages that match conventional commits.

Architecture

Backend APIs

  • use the ports and adapters architecture
  • Handlers should only deal with either HTTP requests or event logic, not business logic
  • Commands should deal with business logic and should not directly access the database