When and how to test decorated classes

[ocean topaz]

Where would you test that DTO's are properly validated by the controller functions? I'm not sure if I should test it at the controllers unit tests, integration tests or if I should create dedicated test suits for the DTO's only.

[regal dagger]

Probably e2e/integration tests would be my approach

[ivory crag]

To confirm. What do you aim to test? It looks like you are trying to test the NestJS code.

[regal dagger]

Sounds like they want to test that their dto fits the business's rules for what should be sent

[ocean topaz]

Yes exactly

I want to test that input validation/sanitization is done properly

That doesn't match the title of this post but I was also wondering, where you would test, that e.g. TypeOrm is doing what you want. E.g. properly cascading/selecting etc.

[regal dagger]

I honestly wouldn't test that. The library should already cover that test. You could make it work, but it'd be a hassle

Testing that you have the correct decorator setup for your validation rules is one thing. Testing that the ORM does what it says it should is another all together

[ocean topaz]

I'm somehow confused why TypeOrm's "save" method is the only method that executes cascades etc. That's why I want to make sure that there is the data I expect in the database after deleting/inserting something

And not only inserting etc. but also that my Application handles errors like unique constraint violations properly

Context: I have setup an external auth provider. The auth provider is configured with an after registration hook to send a request to my nestjs backend. The nestjs backend then stores the user id and email in my database.

There is a unique constraint on the email and externalId field in my database. Now I want to make sure that if for some reason a email would be registered twice, my app handles/notifes me properly

Should typeorm change their error for unique constraint violations my code wouldnt work properly anymore

[regal dagger]

You can validate that your flow for how you handle the unique error works. That makes sense. But you shouldn't try to test that Typeorm throws an exception for to uniqueness without having follow-up logic. Typeorm (or whatever ORM/odm you are using) should already test that. You shouldn't need to test it for them. But testing how you react to that exception of a valid case

[ocean topaz]

But typeorm for example does not have a proper unqie contraint exception type

So I actually have to identify it by the error message and a general type (QueryFailedException)

That's why I'm not very confident about mocking it

[regal dagger]

Like I said, you're writing a text about the reaction to the exception, making sure that logic happens, and that makes sense. I initially assumed you were just testing that Typeorm throws something on a failed unique check, which should already be handled by the library

[ocean topaz]

Also, either I'm doing something wrong or typeorm isn't properly typed. Because e.g. findOne() is typed as Promise<Entity> when it should actually be Promise<Entity | undefined>

[regal dagger]

Welcome to TypeO

[ocean topaz]

What orm or querybuilder do you use for your projects?

I don't like any querybuilder or orm which I have tested already 😦

[regal dagger]

#1156124199874732033

[ocean topaz]

ah thx 😄

[regal dagger]

I use Kysely, and you can find my discussion, and other people's opinions, in that thread 🙂

[ocean topaz]

Then also, since I have to read from the error message and I have no Variable or Type I can check for that error message

How would you make sure that the typeorm error message hasnt changed?

Because if the message changes my code will not work anymore

That's why I thought I have to actually use e.g. an in-memory db and an actual typeorm repository to test my code

[regal dagger]

I'd read the changelog before I upgrade and have tests around my reaction to the error using docker computer to run the same version and database type as what I use in production

No guarantee that sqlite or an in memory DB will throw the same code/message as postgres or MySQL

[ocean topaz]

Yeah makes sense

So you would test that also in a integration test or write a dedicated test suite for that?

[regal dagger]

I'd make it a part of my e2e suite

[ocean topaz]

alright

Thank you for sharing your opinion and methods

Helped me a lot 😄

I'm way more confident about the whole situation now

kysely looks 🔥

[ivory crag]

IMO. If possible, it would be helpful to update the title and description of the thread. Body request validation and ORM look like different concerns to me. 🙂