[TypeORM sample unit test question]

[acfasj]

Feature Test To Be Requested
Sorry for open a qustion issue.
I read the code about apps/typeorm-sample/src/cat/cat.service.spec.ts
and I realize that the test case is repeatting the steps as we develop, it means we need to know very detail about the implementation.
I serach a lot about Nestjs testing with TypeORM, and find an issue comment it address that

I like to write assertions on the result rather than on the way the result was obtained

And I agree with that. IMO, unit test should be simple and dump with assertions about input and output, not the steps how we develop.

Hopefully all you guys could give your comments about that if you see the issue

Thanks for the great repo, it helps me a lot

[jmcdo29]

I think I see what you're getting at, and I get your point: "A unit test should be simple and dumb with assertions about input and output".

To an extent, that's what's going on here: we give an input ('a uuid') to the service and assert the output (oneCat). I do extra assertions on the TypeORM methods, but it's not necessary, especially as there's not really any transformation of the parameters from service method to TypeORM method.

Essentially, it comes down to preference, and if you don't want to assert on the spies about what was called, or passed, that's absolutely fine. I find it gives a bitter stronger tests in some cases, but it does require knowing the implementation which goes against Test Driven Development.

[acfasj]

@jmcdo29 Thanks your reply. Yes, you got me, it is the spies "bite" me, espicially the repo.method.toBeCalledTimes(). And in a more complex situation, TypeORM's createQueryBuilder is more powerful, but at the same time the spies is harder to test.

Since I am a frontend developer, and didn't have much knowledge on backend and database. When I use React, React have a special test renderer and can use jest-dom to simulate the real dom environment, so I can simply mock and assert. When I come to the database world and TypeORM, I think a memory database like is a more proper way like the React test renderer and jest-dom for unit test case. And indeed, TypeORM can use sqlite to handle that , but is not perfect for some database specific feature such as PostgreSQL.

Lets focus on the point, the only thing I care about is, how can I validate the service logic is what I expected. At most of ime, service is all database manipulations. If you want to update a record, you may use repo.update, or repo.save, or createQueryBuilder.update. If I use the spies here to validate the update logic, when I change the source code from repo.update to repo.save, I need to change the test file, too. We do need spy/stup/mock at most of time, and it's very useful, but as you say, it‘s bitter in these situations (event it‘s more stronger). If only I could have some way to essure the TypeORM would absolutely obey my rules/logic, dump and declarative is preffered. Wow, kind of mess of my mind right now.....

[acfasj]

Since it‘s a question and a discussion issue, so I close it, but you are welcome to reply me if you have some ideas