[Adonis V5] HttpContext when writing unit tests in v5?

[aayush123]

Hi,

I'm making a REST backend using Adonis v5 and was writing unit tests for my controller & service methods when I ran into a little hiccup.
My Auth service exposes login method, which takes inputs & auth object (passed from Controller, which in turn receives it from the HttpContext).
Here's the declaration: public async login(inputs: any, auth: AuthContract)
Where AuthContract is import using: import { AuthContract } from '@ioc:Adonis/Addons/Auth';
I was wondering if there was a way to get the auth object or instantiate it in my test so that I can pass it to my Service method while calling it?

Thanks!

[fnoquiq]

Hey, can you share your architecture? I am looking for something similar.

[aayush123]

Well, my backend's architecture is a pretty straightforward MVC architecture.
I have routes defined in various route files and controllers which handle the end-points.
The controllers almost always interact with services, which contain business logic, and transformers, which handle transforming data for responses.
The Services in-turn interact with repositories for all DB-related operations. Other logic is contained in the services itself.

I had started TDD with this project, but then end up in the problem mentioned above. The issue won't let me write tests for any and all Service methods that interact with the authenticated user or any other auth related operation (so far).

[fnoquiq]

Could you share a code snippet from your repository file?

How are you mocking the repository with Lucid ORM?

---

I'm trying to isolate my business logic in the service, to do unit tests on them. The repository pattern seems like a good one, but I would like to know how you are doing the dependency injection?

[aayush123]

Your comment got me thinking about how exactly am I managing my DI.
To be honest, it's my first large scale project with Adonis (did a hobby project a long time ago with v4 I think), and also my first project where I'm actually hard-pressed to manage more things on my own (kinda due to everything not readily available as code snippets, as is the case with frameworks that have been around for a long time).
After reviewing what I've done so far, I've ended up with the singleton pattern, and after reading into the singleton pattern, it seems it might not be a really good idea in the long run, or so the interwebz have told me.

Nevertheless, I'd still like to share my code snippets and would look forward to what you (and the community) think of them.

All my repositories extend a base abstract class, Repository.ts

export default abstract class Repository {
  constructor(public model: typeof BaseModel) {}
  public query() {
    return this.model.query();
  }
  ...
}

I've got implementations of most of the basic db operations such as create, get, update, delete, getWhere etc. here. Most of them are just wrappers around Lucid methods.

Inheriting this, my UserRepository looks like the following:

import Repository from 'App/Repositories/Repository';
import User from 'App/Models/User';

class UserRepository extends Repository {
  constructor() {
    super(User);
  }

  /**
   * Search utility for users
   * @param  inputs         Search filters
   * @param  paginate=false Whether to paginate results or not
   * @return                awaitable queryBuilder
   */
  public async search(inputs = { page: 1 }, paginate = false) {
    const query = this.query();
    return paginate ? query.paginate(inputs.page || 1) : query;
  }
}

export default new UserRepository();

This is where I write per-model custom logic for filtering, or just about anything that I need for a Model. Notice that I've exported an instance (and as far as I've read aka a singleton).
I read about this pattern somewhere here in the discussions itself and I believe @thetutlage had mentioned that this way, we can save ourselves from instantiating classes everywhere we need them.
I still am wondering whether this will have some long term implications/performance implications or not.

Regardless, moving on to services, my UserService looks like this:

import Users from 'App/Repositories/UserRepository';

class UserService {
  public async get(id: number) {
    return Users.get(id);
  }
  ...
}
export default new UserService();

Notice again, that I've exported a singleton here too.

This can be imported into a test and the methods can be tested individually. For eg. my users/crud.spec.ts looks like this:

import test from 'japa';
import Database from '@ioc:Adonis/Lucid/Database';
import Users from 'App/Services/UserService';

test.group('User CRUD Units', (group) => {
  group.beforeEach(async () => {
    await Database.knexQuery().table('users').truncate();
  });

  test('UserService: Create User', async (assert) => {
    const mockUserData = {
      email: '[email protected]',
      name: 'John Doe',
      mobile: '9877899877',
      referral_code: 'ACX',
    };
    const user = await Users.create({ ...mockUserData, password: 'password' });
    const userJson = user.serialize();
    assert.deepInclude(userJson, mockUserData);
  });
  ...
});

That's about it I guess.
I'd love to have your (and everyone else's) thoughts about the architecture and singleton pattern. DI still seems like a new foray to me and since this is only my second large scale project since I started developing, I'd love to learn more and know whether what I've designed so far is good or bad 😃

UPDATE: In hindsight, I think I may have gone off-track from what you asked 😅 . I don't mock Lucid ORM btw, in case that's what you were trying to ask. I just use a separate DB, run migrations before all tests & revert them after.

[fnoquiq]

Thank you so much for sharing your architecture. I am studying structures to start a new project, but I am afraid to complicate things unnecessarily. I found the pattern repository in a project with express and I really liked it. The express project using the repository pattern can be found here.

Unit tests should be pure and therefore there can be no side effects. So the idea was to generate a mock of the userRepository and inject it into the service during the tests.

The fake does not depend on which ORM, as the data is saved in memory.

class FakeUsersRepository implements IUsersRepository {
  private users: User[] = [];

  public async findById(id: string): Promise<User> {
    const findUser = this.users.find(user => user.id === id);
    return findUser;
  }

  public async create(userData: ICreateUserDTO): Promise<User> {
    const user = new User();
    Object.assign(user, { id: uuid() }, userData);
    this.users.push(user);
    return user;
  }

  public async save(user: User): Promise<User> {
    const findIndex = this.users.findIndex(findUser => findUser.id === user.id);
    this.users[findIndex] = user;
    return user;
  }
}

export default FakeUsersRepository;

But in this case I'm using typeorm

class UsersRepository implements IUsersRepository {
  private ormRepository: Repository<User>;

  constructor() {
    this.ormRepository = getRepository(User);
  }

  public async findById(id: string): Promise<User | undefined> {
    const user = await this.ormRepository.findOne(id);
    return user;
  }

  public async create(userData: ICreateUserDTO): Promise<User> {
    const user = this.ormRepository.create(userData);
    await this.ormRepository.save(user);
    return user;
  }

  public async save(user: User): Promise<User> {
    return this.ormRepository.save(user);
  }
}

I'm still starting in this world, I can't say if it makes sense. I'm still a beginner