Testing

At Blobscan, we believe in ensuring that our code not only functions correctly but is also maintainable and robust.

We rely on testing to ensure our solutions meet user expectations.

Philosophy

Focus on Behavior and Requirements: Our tests are designed to validate what the system should do, not necessarily how it does it. By doing so, we ensure that:

• We maintain clarity about the requirements and expected outcomes.
• The code remains flexible, allowing developers to refactor and optimize without constant test breakages.

Avoid Testing Internals: We generally steer clear from testing private or internal functions directly. This aligns with our behavior-driven approach. However, complex internal logic may sometimes warrant its own set of tests.

Testing Tools

Framework: We utilize Vitest, which is set up with a workspace configuration tailored for our monorepo.

Integration Testing: Our integration tests run with a local PostgreSQL database and a fake GCS server, orchestrated via Docker. This ensures our tests mimic real-world scenarios. We employ a specific script to set up these services before initiating tests.

Setting Up Your Environment

To get started with testing, follow these steps:

1. Clone the Repository:

git clone https://github.com/Blobscan/blobscan.git
cd blobscan

2. Install Dependencies:

pnpm install

3. Configure Environment Variables:

Make a copy of the .env.test and rename it to .env:

cp .env.test .env

Then, adjust the .env file as outlined here.

4. Initialize Docker Containers:

pnpm test:setup

5. Execute Tests:

pnpm test

Test Fixtures Configuration

Our test fixtures provide mock data for both PostgreSQL and Google Cloud Storage. All fixtures are housed in the @blobscan/test package.

Structure of the Package

• fixtures: This directory contains separate subfolders with the mock data for each service.

• helpers: Within this folder, you'll find utility functions that helps to load and reset the fixtures using prisma, ensuring a clean slate.

Integration with fake GCS server

The mock data present in the storage subfolder of fixtures, is pre-configured on the fake-gcs-server. This ensures that every time we initiate tests involving storage, the emulator starts with our designated mock data.