Who's using Suites?

[omermorad]

Hello there!

We'd love to hear from companies and teams using Suites in their testing workflows! 😄

Feel free to share:

• Your company / organization name
• How you're using Suites (which parts of your stack, testing approach, etc.)
• Any benefits or improvements you've seen in your testing process
• Any challenges you've faced or features you'd like to see

Your feedback helps us understand real-world usage patterns and guides our development priorities.

Thanks for being part of the Suites community!

[QozbroQqn]

Hi

you didn't say where to share so I do it here.

Company

I dont want my github account to be connected to the company I am working for. So I dont want to tell which company I am working for. But we are maintaining a Vue app backed by NestJs with graphql and prisma. The app is used for planning and managing routes for various services, such as garbage collection, parcel delivery, winter services, and similar areas where it is important to plan and optimize routes and assign drivers.

Some backend stats

• 80+ modules
• 500+ source files
• 1000+ test files for Solitary, Sociable, Integration and E2E tests
• 95%+ test coverage atm (we are still in refactoring process)

How we are using Suites

• We are using Suites for ~6 month
• We split tests in solitary and sociable
  • all sources without dependencies or that only contain exported functions have only a solitary test.
• a unit in our pov is a function and not a class. We dont test classes
  • in solitary tests we test the function isolated with everything mocked what does not belong to the function. If a function f1 is calling a function f2, f2 is mocked even if it belongs to the same class or is private.
  • in solitary tests we test the implementation and not the result unless the result is produces by the tested unit. For example if a function f1 takes two args and f1 just returns the sum, the solitary test will test the result.
  • in sociable tests we test the function with nothing mocked but external dependencies like API calls, DB Clients (including PrismaService) and similar.
  • in sociable tests we test the result and not the implementation. For 99% our sociable tests contains only it('throws ...') and it('returns ...') tests

Benefits or improvements

• clean distinction between implementation and result tests (even beginners understand this pattern)
• faster cause determinition
  • if a solitary test fails => must be the tested unit
  • if a sociable test fails => must be something with a dependency
• TestBed creation and the auto-mocking makes it pleasent and straight forward, even for our juniors

Challenges and features we would like to see

Challenge Auto-Mocking

A great feature would be auto-exposing for sociable tests. Something like TestBed.sociable(SomeThing).autoExpose().without([PrismaService, OthersWhichShouldNotExposed]).compile(). TestBed would then expose automatically all dependencies of SomeThing and the dependencies of dependencies without those declared in an optional array passed to autoExpose().without(). All not exposed but injected dependencies should be mocked.

We came to this because of this:

As great as auto mocking might be, for sociable tests its becoming quite tedious and error prone exposing (or forgetting to) neededed dependencies. Yesterday I had a case in which I wanted to test the result of a unit. I wrote a "return" and a "throws" test. Both were green even though I expected the "throws" test to fail because I knew the needed dependency wasnt exposed. But to expose it, I needed to expose 11 other dependencies. I believe a less experienced dev wouldn't have catched that.

I fear many lying (sociable) tests will get implemented by us resulting in an increased review time for PRs. Tbh I expect to have a lot of them already. That will likely happen if we test a result which dependends of a result by some dependency's dependency. Imagine a service function f1 which will throw if an argument or return value is undefined. If you test "ServiceFunction.foo throws if ..." you will get green if you forget to expose the dependency that contains the function f2 which throws the actual error. If someone changes f2 to not throw anymore, f1 should be red. But it will remain green because of a missing expose and TestBed mocking everything to undefined.

Challenge NodeNext

We were told to migrate our backend from CommonJS to NodeNext. There is still a problem with typings we were not able to resolve. I posted a question about this topic here #811.

Final thoughts

We have a really bad feeling about using sociable tests. They could be a great addition but the fact that they can likely lie is a pain point. Test driven development like in solitary tests is not possible (and maybe not wanted) imho due to the need of exposing everything needed. As for me, if I cannot trust a test, the test is not worth anything.

Currently we discuss about removing/disabling all sociable tests and just use integration tests instead. They are slower but at least they feel trustworthy. But that leads to the question why using Suites at all. For solitary unit tests we could also just use @nestjs/testing.

[omermorad]

Many thanks for this detailed post @QozbroQqn. I'm on vacation right now, but when I return, I'll take the time to carefully review this 🙏🏻

[QozbroQqn]

No problem :) Take your time.

[omermorad]

Ok, after reading your reply carefully, I have a few reflections:

The Reason Suites exists (or Philosophy)

Suites embraces both solitary and sociable unit testing in the Fowler sense. Our north star is trust: avoid brittle tests (false reds) and avoid false greens. We focus on behavior over implementation and keep I/O at clear boundaries.

Your pain points (agreed, but might be also a design smell)

I agree on the ergonomics and safety issue. Manually exposing chains is error‑prone. Missing an exposure can create false greens because an unconfigured stub returns undefined (which is in fact still a value) and can accidentally satisfy guards.

But I also want to be transparent with you, I think needing to expose many dependencies to exercise one behavior is itself a smell. It indicates high fan‑out, fuzzy boundaries and branch pressure that make tests harder to trust and maintain.

Direction I'm Proposing

• Two explicit sociable "modes" that are hard to misuse:

  • Partial: expose a few trusted collaborators, everything else fails fast if touched (no silent undefined anymore).
  • All: expose the transitive in‑memory graph for ergonomics; boundaries (DB/HTTP/queue, etc.) stay mocked by default.

• Safe defaults: fail‑fast in Partial, boundaries respected in All.

• Clear conflict rules: no mixing expose/boundary/mock on the same token - lite and simple mental model.

So What's Next?

• I will open a dedicated issue to finalize sociable semantics (modes, defaults, boundary rules, migration path) and link it here.
• I will cross‑reference the existing Auto‑Expose discussion so we keep one coherent thread.
• NodeNext typings remain tracked separately; we’ll follow up there.

What do you think?

[QozbroQqn]

Thank you for your time.

first days back at work. I was on vacation for 3 weeks until yesterday. Need some time to get back into things. I will review it shortly.

[omermorad]

Sure. Whenever you're ready 🙏🏻

[QozbroQqn]

What do I think? tldr:

Your proposals sound great. We would use all. I love the fail-fast idea with no silent undefined.

---

I spoke with a friend of mine (working for VW) about solitary and sociable tests in general. I also reread Martin Fowler's blogpost about Unit Tests.

There is no clear rule regarding sociable tests and which dependencies a unit should expose. My friend and his team (they dont use suites) follow this rule:

Sociable tests expose direct dependencies only (except PrismaService or similiar external APIs) and not the dependencies of dependencies

With this example:

class Foo {
  constructor(
    private readonly a: A,
    private readonly b: B,
    private readonly c: C,
  ) {}

  foo(data: Record<string, unknown>) {
    const someVar = data.someVar;
    return this.a.bar(someVar);
  }
}

class A {
  constructor(private readonly d: D) {}

  bar(arg?: string) {
    if (!arg) this.d.doSmthAndThrow();
    return true;
  }
}

class D {
  doSmthAndThrow() {}
}

a sociable test for Foo.foo would only expose A, B and C but not D. They do this because they claim:

Since the interaction between Foo and D exists on A, and A tests the interaction between A and D. Transitivity, in other words. If this is successful, it must also be successful for Foo and D.

But WE follow this rule:

Sociable tests expose all dependencies including dependencies of dependencies (except PrismaService or similiar external APIs)

We do this because we claim:

Even though interaction between Foo and D exists on A, I still can change A's functions so that Foo should fail but wont if we mock D

And actually we can easily produce such tests. For example:

describe(Foo, () => {
  it ('throws if data does not contain "someVar"', () => {
    // ...
    const { unit } = TestBed.sociable....
    const data = { a: 1 }
    
    expect(() =>unit.foo(data)).toThrow(...)
  });
});

With this approach I can make sure if someone changes D.doSmthAndThrow, the test for Foo.foo will be red. But if I mock D.doSmthAndThrow to throw, then the test will always be green. I see no easy and safe solution to this but auto-exposing.

[omermorad]

@QozbroQqn I've been working on v4.0.0, it is ready under the alpha distribution tag (please look here: https://github.com/suites-dev/suites/releases/tag/v4.0.0-alpha.0)

Regarding the features you've raised - Auto-Expose & Fail-Fast - these will be coming in v4.1.0. The fail-fast mode will prevent the "false green" scenario you described, and auto-expose will eliminate the boilerplate of manually listing all dependencies.

The reason I'm splitting the releases is that v4.0.0 has become urgent - users are blocked on NodeNext issues and postinstall script problems. Rather than delay it further to include auto-expose/fail-fast, I want to get the critical fixes out now, and then follow up quickly with v4.1.0 which will include your requested features.

Since you have such extensive real-world usage, I'd love for you to test v4.0.0-alpha. Your feedback would be great.

Make sure to follow https://suites.dev/docs/overview/installation/#type-reference-configuration and to add /// <reference types="@suites/di.nestjs/types" /> in the global.d.ts file as well

[QozbroQqn]

Thank you for your hard work. :)

I will test it. But I cannot say when. Our refactoring process is on hold because the winter season has begun for winter services and we currently have no free capacity. Officially, we will continue working on refactoring in April at the earliest. But I think we have a few story points left over in the sprints to continue working on refactoring here and there.

I myself am planning to do a little refactoring this week or at least next week so that I don't completely lose touch. I'll definitely come by to test it out.