Skip to main content

Testing in Vyndara

Vyndara follows a Test-Driven Development (TDD) approach because, let’s be honest, debugging a huge system without tests is like trying to find a black cat in a dark room… that might not even be there.

By writing tests before implementation, we ensure that changes don’t sneak in like a ninja and break everything at our automated releases.

Why TDD?​

  1. Early failure detection – If something breaks, we want to know now, not after a customer reports it.
  2. Code confidence – No more "Works on my machine!" excuses.
  3. Refactoring safety – Change things without worrying about unleashing chaos.
  4. Faster debugging – Bugs are caught when they’re tiny and harmless, not when they’ve evolved into system-destroying monsters.

Structure of Testing​

important

Within Arematics you should try to avoid mocking data. We ALWAYS prefer using an actual database, cache or other stuff with data in it. Only if there is really no other way, use mocks.

1. Unit Tests​

  • Tiny, fast, and cover individual functions and components.
  • Written before implementation, because future-you will thank past-you.
  • Runs so quickly, you can’t even get a coffee before they finish.

2. Integration Tests​

  • Ensures different services play nice together (unlike some developers in code reviews).
  • Critical for database queries, API calls, and Kafka event handling.
  • Think of it as making sure the orchestra sounds good together, not just individual instruments.

3. End-to-End (E2E) Tests​

  • Simulates real user interactions—because customers don’t care if the function worked in isolation if the whole app explodes.
  • Ensures that clicking a button doesn’t unexpectedly delete the entire database (we hope).

Behavior-Driven Development (BDD)​

Vyndara also uses Behavior-Driven Development (BDD), as defined in this document, because testing shouldn’t just be for developers—non-tech folks need to understand it too.