unclear documentation about test setup with circular dependency of repositories

[derdeka]

Description / Steps to reproduce / Feature proposal

According to https://loopback.io/doc/en/lb4/Testing-your-application.html the database.helpers.ts should look something like this:

export async function givenEmptyDatabase() {
  const categoryRepository = new CategoryRepository(testdb);
  const productRepository = new ProductRepository(
    testdb,
    Getter.fromValue(categoryRepository),
  );

  await productRepository.deleteAll();
  await categoryRepository.deleteAll();
}

But because of belongsTo and hasMany relation for me it has to be something like this (circular dependency):

export async function givenEmptyDatabase() {
  const categoryRepository = new CategoryRepository(
    testdb,
    Getter.fromValue(productRepository),
  );
  const productRepository = new ProductRepository(
    testdb,
    Getter.fromValue(categoryRepository),
  );

  ...
}

Is it really necessary to setup all repositories like this for the tests as the ioc container is doing the same thing automatically? My guess is, that the test database should be bound to the test application and that's it.

Current Behavior

Unclear documentation about test setup with circular dependency of repositories.

Expected Behavior

Improved example - what to do with circular dependencies?

Acceptance Criteria

• Find the correct way to write the integration tests for repositories with circular dependencies.
  • Either figure out a working solution or fix the existing code.
• Update the documentation on https://loopback.io/doc/en/lb4/Testing-your-application.html with the new approach accordingly.

[DatGuyJonathan]

I am experiencing this as well. Have you been able to get pass the circular dependency issue, @derdeka ?

[derdeka]

I still have this problem with circular dependencies of the repositories and did not found a solution yet.

@bostjanpisler @bajtos according to git history you added this part of the documentation. Can you give a hint how this should work with circular dependencies?

[derdeka]

@raymondfeng @dhmlau Could you give a hint please?

[raymondfeng]

@jannyHou ^^^?

[Jamesters]

I have no idea if this is the correct solution, but it hasn't changed the functionality of my application.

I guess, if all you're trying to do is to run a deleteAll(), then it shouldn't matter if the dependent repositories exist or not, so I added a ? in my repository constructor to make the argument optional (I am extremely new to TypeScript, so please forgive me for not using the correct terminology).

export class CategoryRepository extends DefaultCrudRepository<
  Category,
  typeof Category.prototype.id
> {
...
  constructor(
    @inject('datasources.db') dataSource: juggler.DataSource,
    @repository.getter(ProductRepository)
    protected productRepositoryGetter?: Getter<ProductRepository>,
  )

I don't believe there would be a situation where loopback would call the constructor without a Getter... outside of your test environment (although I am NOT speaking from experience or knowledge, just an assumption).

Then, in your database.helper.ts, you can do 1 of them (or both if you add the ? to both repositories) without the extra parameter

export async function givenEmptyDatabase() {
  const categoryRepository = new CategoryRepository(testdb);
  const productRepository = new ProductRepository(
    testdb,
    Getter.fromValue(categoryRepository),
  );
...

It's important to note that this does not give you any of the functions of the missing dependency ... such as categoryRepository.products(id).find() ... so if you want to use these, you'll probably have to plan your helpers and tests accordingly and separate the functions so that 1 of the circular dependencies exists at 1 time, and the other at another.

[jannyHou]

@derdeka Have you followed the documentation here to define the relations?

See belongsTo relation and hasMany relation

[jannyHou]

If the circular dependency error is caused by the json schema generation, this PR is fixing it.

I may need more time to setup the test to check if the circular repositories fails due to the same reason like ^.

[Jamesters]

@jannyHou the problem is that if you use both the belongsTo in one repository, and the hasMany in another repository, you end up with a circular reference in the repositories, and can't use the existing xxx.repository.ts in a test.

RepositoryA hasMany RepositoryB - so we need a Getter.fromValue(new RepositoryB) before we can create a new RepositoryA.

Not a big deal until you also say RepositoryB belongsTo RepositoryA, because then you need a Getter for RepositoryA to create RepositoryB, but you can't do a Getter.fromValue(new RepositoryA) since you can't create a new RepositoryA without already having a RepositoryB.

I don't think it's related to issue #2628 . This is a problem where you can't create the repositories in the tests since they both need to be created before you can create either. We aren't even going to get past the initial compile for the test (and you shouldn't since you're missing arguments).

lb-tsc es2017 --outDir dist

src/__tests__/helpers/database.helpers.ts:13:36 - error TS2554: Expected 2 arguments, but got 1.

13   const categoryRepository = await new CategoryRepository(testdb);
                                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  src/repositories/category.repository.ts:27:5
    27     @repository.getter('ProductRepository')
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    28     protected productRepositoryGetter: Getter<ProductRepository>,
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    An argument for 'productRepositoryGetter' was not provided.


Found 1 error.

[derdeka]

@jannyHou
Yes, i followed the documentation, but i think thats not the point. This is not about the usual circular dependency problem of models. This is about injecting repositories in constructors of repositories, which depend each other.

[mathiasarens]

I have the exact same problem. How to set up the repositories in integration tests for example if you use the hasMany annotation on one side and the belongsTo annotation on the opposite side. The dependency injection framework solves this issue. But how can I do it programmatically?

[jannyHou]

OK I reproduced the error.
We have unit and acceptance tests for the hasMany+belongsTo relation in https://github.com/strongloop/loopback-next/tree/master/examples/todo-list/src/__tests__

I will dig more of writing the integration tests.

[derdeka]

@bajtos Could you please take a look into this issue? I would like to get deeper into lb4, but this prevents me and other users to write useful tests. As no one has an answer to this since more than a month, i guess i'm implementing it in a wrong way. Do you have some hints?