Add test infrastructure and baseline tests

[PureJoyMind]

Summary

The project currently does not have any automated tests. I’d like to contribute by setting up a test infrastructure and adding an initial suite of tests, so we can start building confidence in future changes.

Proposed approach

I was thinking of going the standard approach.

• Set up the project structure for tests (creating the test folder in the solution, etc.)

• Add basic unit tests that cover critical components

• Add test utilities/helpers to simplify writing future tests such as class fixtures for shared data between tests

Roadmap

• Starting from unit tests and achieving acceptable coverage

• Creating integration tests for the apis created using FastCrud, so if we change the underlying implementations we can know if the endpoints work as expected.

I was also thinking that for integration tests, the sample api project could be useful. It can have more types of endpoints which helps with two things: 1. Showing the potential of FastCrud 2. Having a more complete integration test

Benefits

Provides safety net for refactoring.

Makes it easier to contribute features without worrying about breaking anything existing.

Encourages test-driven contributions in the future.

Questions for maintainers

@ashkanRmk
Should the initial focus be unit tests only, or also some lightweight integration tests? In other words, should I separate the PR for unit tests and integration tests separate or have them all in one PR?

[ashkanRmk]

Thanks a lot for jumping on this. really appreciated! 🙌

Let’s start with unit tests only in the first PR. Then we’ll add integration tests in a follow‑up PR.
Reason: I want to lock in confidence around the core building blocks (services, repositories, mapping, validation, etc.) before we layer in end‑to‑end coverage. That way if we see a failure later at the integration level we know it’s a wiring/config issue, not a missing fundamental behavior test.

Guidance for the first (Unit Test) PR:

Scope: Core abstractions + key service logic (e.g. CrudService methods, validation flows, any utilities with branching logic).
Style: One test class per public method (pattern you already outlined is perfect).
Assertions: Prefer FluentAssertions (readability, better failure messages).
Test Data: Keep super lean; if you find yourself repeating setup, add simple builders/factories (no premature generic frameworks).
Determinism: No network, no real DB, no file system. Use in‑memory fakes/mocks.
Naming: FastCrud..Tests.Unit (as you proposed). Helpers can go under a Tests.Common (or Tests.Shared) project later if needed.

Acceptable milestone for first PR:

Happy if we cover the “happy path” + key failure/edge cases for CrudService and any transformation / filtering logic.
No need to chase a percentage yet, but roughly: cover what would make refactors scary without tests.

After merge (Second PR - Integration Tests):

Use the sample API project (great idea) as the subject under test.
Spin up minimal host (WebApplicationFactory or equivalent).
Use in‑memory / ephemeral DB (or Testcontainers later if we need provider realism).
Cover: endpoint contract (status codes, shape), basic auth/validation flows (when present), and interaction sequencing.
That PR can also introduce a lightweight test fixture pattern.

So plan:

PR 1: Unit test infra + initial unit coverage.
PR 2: Integration test infra + first endpoint coverage.

Thanks again. this is a big step toward making the project safer to evolve.

[PureJoyMind]

Sure thanks for making things clearer! this helps a lot, knowing where to put my focus currently. I wanted to use shouldly, because of the licensing changes of FluentAssertions and I also thought the syntax is as readable as FluentAssertions. I've worked with both in different projects. I'll change to FluentAssertions in the next commits soon.