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?