[Question] Improve testing experience (or how to get rid of jest)

[DavidVaness]

Question

Hello @samchon,

Writing E2E tests with Jest is just a terrible dx. Nestjs supports it with SWC, but I know that SWC is not supported with nestia. On your Homepage you mention waiting for STC, but STC is officially dead, see here https://github.com/swc-project/swc/issues/571#issuecomment-1915966297

I spend some time to look through your examples and documentation - and tbh the testing strategy is the biggest problem we have, using nestia in production. I am even considering removing nestia and typia, just to get rid of jest and enable a quick dx for testing.

What are your thoughts on how to improve this? Imho the docs need to get improved on this

Other users of Nestia please chime in, maybe there is something I missed.

[samchon]

I'm sorry for cannot be helpful. No way in jest.

If you can't adjust below e2e testing strategy, I've no idea.

https://nestia.io/docs/e2e/why/

[DavidVaness]

Thanks for the quick reply @samchon! Looking at your code here, you removed jest completely, but you replaced it with your own testing framework.

I believe this works for smaller projects that are not enterprise level and dont have many devs. My Devs swap often, are not english native speakers and they profit from a "clear" structure. The benefits of having a Testing Framework that is well known, properly documented and well integrated helps immensely.

So while I made the leap and jumped to nestia and typia for their great enabling powers on typechecking and ease of use, It constraints my team to stick with Jest because its properly documented and offers the QoL selectors everybody is familiar with.

Maybe its different for other teams

[samchon]

As jest does not compile (by tsc), not possible to use @TypedBody() like decorators, but only @nestia/sdk is allowed.

By the way, if you can accept skipping the request and response bodies' validation, you can disable the @TypedBody()'s validation features by configuring NoTransformConfigurationError.throws = false like below. However, I cannot sure this approach is right behavior due to it really disables the validation logic.

@DavidVaness, if you also think this approach is acceptable, I need to document this approach to the Nestia guide documents; https://nestia.io/docs. By the way, I don't know where to write the content. If you send a PR about the document, it would be great. Even though you don't have afford to send a documentation PR, please send me an example code utilizing the approach the NoTransformConfigurationError.throws = false way.

import { NoTransformConfigurationError } from "@nestia/core/lib/decorators/NoTransformConfigurationError";

NoTransformConfigurationError.throws = false;

[samchon]

@DavidVaness By the way, I'd actually used my testing approaches in many commercial projects.

This is not a commercial, but an open source project that would be a good reference that how big project utilizes the way.

https://github.com/samchon/shopping-backend

[DavidVaness]

@DavidVaness By the way, I'd actually used my testing approaches in many commercial projects.

This is not a commercial, but an open source project that would be a good reference that how big project utilizes the way.

https://github.com/samchon/shopping-backend

Will check on it, thanks @samchon

Today I am evaluating the approach to create a new package (monorepo), that uses vite and vitest+ nestia sdk.

On startup I used fetch to query the BE health to check if backend is up and then execute the tests (can post snippet)

That way I get vitest support for vs code and all the known testing goodies

[kalmigs]

@DavidVaness, so it's by calling the actual API? how about unit testing, for that use jest? would love to see your approach, looking forward to it!