NestJS Testing Tutorial | Unit and Integration Testing
Жүктеу.....
Пікірлер: 178
@jon18673 жыл бұрын
Your Nest videos are easily the best I've seen. Could you do another one on testing where you set up a Development database using migrations, and then only do E2E testing with the database as a part of the testing.
@mariusespejo
3 жыл бұрын
thanks! you’re thinking like a true full e2e where it actually writes to a db instead of mocking it out? Sure I can potentially make something for that
@jon1867
3 жыл бұрын
@@mariusespejo I would absolutely love that. I spent my day setting up a docker and figuring out how to use a node environment to choose which one to spin up upon test. But I've been having a hell of a time with jest dependencies being all messed up for some reason. I appreciate you!
@isurumaldeniya95363 жыл бұрын
Brother, you are a life savior. I look for many resources but couldn't find that overriding thing. Thanks so much, brother 😁👍👍 Subs to your channel
@mariusespejo
3 жыл бұрын
Awesome glad to help, thanks!
@MrSpiftire3 жыл бұрын
Great introduction. I've been banging my head trying to get mocking to work while using typeDI and typeORM. Might just switch my whole backend to use NestJS after watching this =)
@mariusespejo
3 жыл бұрын
great! I haven’t tried typeDI but if you’re definitely looking for a DI-based framework you can’t go wrong with nest, and it’s got great integration with typeorm so you’re also covered there
@R3flexx2001Ай бұрын
great work, very well explained. greetings from Argentina 🔵⚪🔵
@timothymm2 жыл бұрын
More great content. The music is cool and soothing to start, and glad you dropped it as the 'real' content started. :)
@mariusespejo
2 жыл бұрын
Thanks! I mostly don’t add music in newer stuff, there’s a thin line between it being entertaining and potentially distracting
@cendekia3767 Жыл бұрын
thanks for awesome tutorial video, watching your video with speed 1.5 is always my way for running through all of it then begin to coding :)))
@mariusespejo
Жыл бұрын
Glad to know you can still understand me at 1.5x haha thanks!
@alexandermarthius55933 жыл бұрын
Crystal clear as usual, Great video Marius!
@mrarc1973 жыл бұрын
I really miss git repository here :( Sometimes when you want to jump from file to file its really difficult to switch between different timestamps in video.
@mariusespejo
2 жыл бұрын
thanks for you input, I do need to work on providing source code along with the content
@MrBadsectorr
2 жыл бұрын
@@mariusespejo that would be greatly appreciated :)
@lucascyrne63013 жыл бұрын
Dude, you rock! Congratulations for your amazing work :)
@dimitrisbellos01Ай бұрын
Hey, I am looking for a setup for test suites in NestJS, but with addition of factories for classes, in order to help me with seeding and "Arrange" Step of the Test. Any idea where to watch that? Especially, for complex schemas where i.e. I want to test a module, which every entity depends on the creation of others.
@chronorus2 жыл бұрын
Great tutorial. Your efforts is truly appreciated
@mariusespejo
2 жыл бұрын
Thank you!
@leofreiitasАй бұрын
Thank you, the unit test part was perfect, the e2e I would prefer not mocking anything, but thanks anyway for the good content
@mariusespejo
Ай бұрын
Yup I actually agree, overtime I’ve found it better to actually just run tests off of a real database to get e2e as close to real as possible, but it does require a little extra setup. thanks for stopping by to comment!
@i_am_Avdhoot Жыл бұрын
@Marius Espejo, how to override multiple services in createTestingModule? My controller A is dependent on service B,C,D
@aomadeira3 жыл бұрын
Great content you've provided here sir! Just wanna leave a quick note that if you've created a custom class for your Repository you'll have to write "provide: UserRepository," instead of "provide: getRepositoryToken(User)," Keep up the good work!
@mariusespejo
3 жыл бұрын
thanks Anderson! good note, I haven’t actually tried making a custom class for repositories yet, will take a look at that
@rukeeojigbo22213 жыл бұрын
Thanks a lot tried clicking the subscribe button to subscribe twice...
@user-qs7kj1ex8z2 жыл бұрын
thank you so much, you've put everything on the shelves.
@mariusespejo
2 жыл бұрын
You're welcome!
@adamprice11693 жыл бұрын
any chance of the starter code so people can follow quickly without much set up
@tusharroy61823 жыл бұрын
so clear, Thank you so much would like to see more of these.
@mariusespejo
3 жыл бұрын
thanks Tushar! definitely more of these in the future. Anything specific you were hoping to be covered?
@tusharroy6182
3 жыл бұрын
@@mariusespejo A Project! I would be happy if you can build a project connecting all the topics that you have covered so far. Would be really awesome to see how these things work together. Thanks
@romeoobane99952 жыл бұрын
Really helpful tutorial, clear and straight forward. Thanks much!
@explainedbyexample Жыл бұрын
How to do e2e test on getManager().query(). While doing so, it always takes default connection
@damianlluch2 жыл бұрын
Hello, I have tried to do the video, but I try to connect to the DB all the time... my way is to simulate the service call, that
@daisietrains9981 Жыл бұрын
Hey! thanks for the video!. Im trying to create test filed on an existing project, npx nest generate test place, place being the name of the module i want to test. I get "Invalid schematic "test". Please, ensure that "test" exists in this collection.". :/ Do i need to install it separately?
@mariusespejo
Жыл бұрын
Invalid schematic means it’s not supported for generate, you’ll just have to make the file manually.
@EstebanHelgueroCardiff6 ай бұрын
Hi Marius! Question, should we always create a unit test for our service? Or should we just create an integrarion test? I want my test no to be related to the implementation only on the output of the service. What do uou think?
@mariusespejo
6 ай бұрын
Having a mix of both is good but whether or not you should always do unit tests is up to you. If you had to pick one to focus on, definitely the integration tests are more valuable.
@developerbythegraceofjesus41942 жыл бұрын
Yes for the end to end test so that your E2E tests act as a living documentation . Thanks
@ahmedjumaah97272 жыл бұрын
Hi Marius, following your video (e2e testing), I keep getting this error: Nest can't resolve dependencies of the JwtStrategy (AuthService, ?). Please make sure that the argument ConfigService at index [1] is available in the AuthModule context. I tried the overrideProvider for ConfigService, but no hope. Any ideas? Thank you
@mariusespejo
2 жыл бұрын
That means you didn’t register the config module in your auth module. Alternatively you can register it globally docs.nestjs.com/techniques/configuration#use-module-globally
@ahmedjumaah9727
2 жыл бұрын
@@mariusespejo It is registered globally in the appModule. I added it into the authModule and now I get: Nest can't resolve dependencies of the UserModel (?). Please make sure that the argument DatabaseConnection at index [0] is available in the MongooseModule context.
@mariusespejo
2 жыл бұрын
I mean it’s telling you exactly what the problem is, the module you’re trying to use is missing dependencies. In a test not all of your modules are necessarily registered like in the real app, so it’s not able to find things. That means in your test you either need to add those missing dependencies in the test module, or you need to mock them
@ahmedjumaah9727
2 жыл бұрын
@@mariusespejo Hi again, I resolved it by mocking configService. Thanks man :)
@mariusespejo
2 жыл бұрын
Glad you got it figured out!
@zzjuandaaz Жыл бұрын
Lovely tutorial
@tamasmolnar4157 Жыл бұрын
You saved my day. Thank you.
@prashantpandey82812 жыл бұрын
Great Video
@anothermouth70772 жыл бұрын
@27:40 integration tests begins
@syrlmhmd2 жыл бұрын
You saved my day, thank you.
@matheusvieira3731 Жыл бұрын
Hey man, in the first test example, how can I test if my validation with class-validator are working? example: test if my response have a status code of 400 if no nome is provided, if the message contain "no name provided"? I'm trying this, but I don't know how :(
@mariusespejo
Жыл бұрын
I actually did cover exactly how to do that in the video towards the end, make sure to watch the whole thing 🙂
@jane_93182 жыл бұрын
you are the best!, thank you!
@mariusespejo
2 жыл бұрын
You’re welcome!
@meni181818 Жыл бұрын
on the service tests, your mock implementation of create() is not creating an id. i don't know why the test of it passes.
@mariusespejo
Жыл бұрын
Create() doesn’t create the ID, the save does (which is where inserting would actually happen). And you should notice that the save mock does have ID creation in it. That’s why the test passes
@dawid_dahl Жыл бұрын
Thank you kindly for this video.
@simplyTaddo Жыл бұрын
Easy and helpful
@amirhasansafizade21282 жыл бұрын
Amazing Video!
@connieleung963 жыл бұрын
Excellent tutorial. where were you 1 year ago? I had to learn testing the hard way.
@mariusespejo
3 жыл бұрын
A year ago? likely being a bum and not making videos haha glad it helped you!
@ateebahmed22373 жыл бұрын
Great content.
@be3otech6 ай бұрын
Great tutorial. and can you put repo link please to make it doc for me ?
@acommunistdwarf2 жыл бұрын
Thanks man ... really nice groundwork for us to build on top. I'm enjoying myself doing some old school TDD (is this still a thing?) on an idea I'm having and one thing I'm trying to achieve is that in the name of the technique, iow the unit tests should drive how I design my units and the integration tests how I design my integrations. At the 27min mark, there is a comment on changes impacting the test code ... but wouldn't that be exactly the reason why you are writing them? I mean, you want to have an asset that tells you if any of the changes performed in your existing code base is breaking it, also, if the tests should be driving the design, then I would think it's a good idea to write them first and let them fail, then your redesign now has a very concrete objective, to pass the tests. This has limitations but seems pretty fun to do and makes writing tests much less cumbersome (and with a slight lesser feeling of worthlessness?) and one I can tell right away is that it should not dictate how the unit being tested will work, but instead rely on testing its Inputs and Outputs (Black Box Testing).
@mariusespejo
2 жыл бұрын
Yeah some good points. Yes in general your tests should act as a safety net to capture any moment that you MIGHT have broken previous functionality. That is precisely the purpose of tests. However IDEALY your tests should not simply be a mirror of your exact implementation details. If I have a test that asserts something is created, it shouldn’t matter exactly HOW it was created. Otherwise you’re really just testing implementation details and that leads to brittle tests. That’s the point I was trying to make around the 26:50-27min mark, that in ideal terms I should be able to change the underlying query but as long as it still results in the same expected result, then my test should pass. That’s basically what you pointed out with black box testing so I’m not sure where the disconnect is, it sounds like we agree on the same core principle. However I was calling it out specifically because at that example unit test, if you mock the dependency, it’s a bit hard to create a mock that doesn’t ultimately behave or mirror your implementation details. Also this video was really more a lesson on how to setup tests for Nest specifically and not necessarily on TDD. However I actually do think TDD is a great practice, in general anything that promotes designing the API first in some way is a good thing
@acommunistdwarf
2 жыл бұрын
@@mariusespejo thanks for the answer man, no disagreement indeed, I just fell the need to get that point you made and bring the TDD talk. Thanks again for the video man, much success!
@AlexanderDobrin-ov4wc11 ай бұрын
Could you suggest a clean way of how test db should be configured for tests. Sould entire database module be mocked, or just configuration file changed, or environment. How migration and seeds should be implemented. Maybe you know great article about all of this?
@mariusespejo
11 ай бұрын
It depends entirely on how “real” you want it to be. You could literally spin up a database like mysql/postgres with docker for example and set it up in such a way that it starts fresh per test. Run migrations, seed data, trigger your queries and make your assertions, wipe the db, rinse repeat. But the tradeoff is complexity and tests running slower. It’s also more complex doing that on CI, depending on your setup. Next best thing, maybe the same thing but run sqlite in memory. Tradeoff is that if you’re not actually using sqlite in production then there are API and behavior differences compared to your real DB. Next option is mocking the database layer entirely, perhaps at the ORM level. It’s easier, you don’t have to deal with migrations, tests are quick. But the tradeoff is your tests are the farthest away from being “real”. So it all boils down to how much confidence do you want your tests to produce and how complex of a setup are you willing to put up with
@prasadb33992 жыл бұрын
Hello Marius, Great tutorial.
@mariusespejo
2 жыл бұрын
Hello! Glad you liked it!
@PterPmntaM2 жыл бұрын
Great video man, but I have a problem, I have a folder with multiples resources into, this called, phase-two, when I try to run any test file, doesn't work, show me a message about the Service Name can't be found it and other stuff. On the other hand, the first phase, called phase-one, doesn't have any issue, but in this folder the module is a same level of the test file generate by Nest. Do you know any solution for that?
@mariusespejo
2 жыл бұрын
Generally in tests if it says it can’t find a dependency it’s because you test module didn’t include it (or a mock of it) so it doesn’t know what to inject, hence it will say can’t be found
@PterPmntaM
2 жыл бұрын
@@mariusespejo Thanks, I found a video where solved that problem.
@bodolawale54483 жыл бұрын
Lovely video. Thanks A Lot
@mariusespejo
3 жыл бұрын
thanks! 🙏 glad you like it
@lesleytheman22 Жыл бұрын
Thank you! This helped me a lot!
@mariusespejo
Жыл бұрын
Glad it helped!
@mateus1357 Жыл бұрын
Great content, and if I have logic in my service layer that can return errors like 404, 409, how do I test this in the controller and service layer?
@mariusespejo
Жыл бұрын
Lets say for example your service layer throws “EntityNotFound” which the controller catches so it can then throw NotFoundException. Then in your controller unit test the service mock for one of your tests bust be setup to throw EntityNotFound, then you can assert NotFoundException was thrown. Similar idea for the service. If you were doing an e2e test then similar idea but instead you’d actually assert that you got a 404 status response. Hope that helps
@mszado153 жыл бұрын
GREAT. NICE JOB!!!
@user-bu3hz5be5w3 жыл бұрын
Thank you very much, it helped a lot!
@Black1Sabbath1002 жыл бұрын
Excellent video, love the way you explain things. So simplified, easy to go through and grasp knowledge. Have you consider doing Udemy courses? Cause I strongly believe people would like to aquire more depful content from you.
@mariusespejo
2 жыл бұрын
Yeah I’ve thought about making paid courses, but for now it’s all just here for free :)
@stainlesssteellemming38852 жыл бұрын
27:10 One comment about the 'expect().toBeCalled()' assertions making the tests brittle. They already *are* brittle, because you are implicitly relying on the underlying implementation in your choice of which methods to define in your mockUserRepostory. For example, if you switched to using insert() and query() in the service, your mockUserRepository probably wouldn't have those methods defined, so the test would fail anyway. For a real life project, I am needing to effectively mock a lot of prisma in this manner. I'd also potentially like to be able to inject different provider overrides for different tests: any ideas how? Great tutorial though, thanks.
@mariusespejo
2 жыл бұрын
Fair enough good point! I feel like mocking ORM/query builders in general always leads to that. I think the only way to get around that is by having an extra layer of abstraction so that you’re not dealing with the underlying implementation directly. E.g. for typeorm for example you can do custom repositories: orkhan.gitbook.io/typeorm/docs/custom-repository I imagine that would result in just needing to mock a single method from the repo. As for your override question, you can maybe use multiple describe blocks with their own test beds for each set of tests with different overrides. Not sure there’s a better way than that
@stainlesssteellemming3885
2 жыл бұрын
@@mariusespejo Thanks. And, of course, this is true of any dependency mocking. You try and mock the smallest part of the dependency's interface, but that means understanding the implementation details of the code under test. Eventually, you need a test suite to check that the mock implementation works correctly.
@rained23JMTi3 жыл бұрын
In unit test, I saw that mostly we mock everything just to get the expected result, but if we mock something it for sure to be an expected result right ? I am curious let say in my service method contains some logic, how will this code be tested ? or is that we dont really need to test it ? most of unit testing video/ tutorial only showthe case where the service method that is simple, like have single line of code and mock dependency method that being called. What if I have a service method as below logic(input): { // do something with input example data transformation return input.toUpperCase(); } when we write expect(service.logic(input)).toEqual(expectedResult); is that method really executed ? meaning it really call the exact service.logic method and return an upper case of the input ?
@mariusespejo
3 жыл бұрын
We mock the dependencies but not the actual underlying logic of the thing your testing. In your example you’d unit the service by making sure that the output is transformed, your example would require zero mocking. But let’s say it uses a repository to select the input from the database, then your service logic uppercases it prior to returning, then your mock repository should return some mock return value and you would assert that you not only got the mock value but also that it’s all uppercase
@apatt552 жыл бұрын
Great video! Any idea on how to mock a request session using supertest? My controller pulls data off of the request session. I'd like to be able to mock that in my e2e test
@mariusespejo
2 жыл бұрын
In theory you just need a mock middleware which puts data inside req.session, and that data could be whatever you want. Or otherwise maybe you could mock other parts of the pipeline, e.g. if you had a guard that checks data in session, you could mock that guard instead
@raimundoneto4557 Жыл бұрын
do you have an example using prism?
@vceolin39083 жыл бұрын
AWESOME VIDEO, THANK YOU SO MUCH! subscribed also
@mariusespejo
3 жыл бұрын
thanks! 🙌
@warraupe93733 жыл бұрын
Very nice!
@PiyushChauhan20113 жыл бұрын
Thanks what are your thoughts on testing the typeorm entities? How do we test db constraints in entity or add validation at entity level using class validator?
@mariusespejo
3 жыл бұрын
You’re meant to utilize class validator on the dto not the entity, because you’re validating the data that’s coming in from a client not data coming out of the db which is what the entity classes represent. You can involve a real in-memory db if you wanted to but I don’t really see a ton of value in testing db constraints, it’s not your job to verify that the database is working as it’s supposed to. However that’s not to say that testing the integration with a real db is useless, there is value in doing a true end-to-end integration test. But the point is to test the integration not the individual database constraints
@JustinMorganYXX2 жыл бұрын
VS Code TS Auto-Import setting in preferences: Typescript > Preferences > Import Module Specifier. :)
@mariusespejo
2 жыл бұрын
Ah thanks didn’t know there was setting for that lol
@JustinMorganYXX
2 жыл бұрын
@@mariusespejo I coincidentally had the same issue this week. Glad I could help.
@_alkutab6780 Жыл бұрын
perfect man
@grimmersnee3 жыл бұрын
nice explanation. How would you approach testing endpoints that have guards / decorators and interceptors etc..
@mariusespejo
3 жыл бұрын
I would test them as usual and have those things run for real. However it depends on the underlying implementation behind those decorators. For example if you have an auth guard that integrates with an external identity provider, then I would either mock that guard or use a different passport strategy specifically for testing. RBAC guards I would definitely try to test for real, but that’s where your auth mock will come into play (e.g simulating different users with different roles). If you do need to mock any of it, there’s a small detail in the video where I briefly show that you can also do things like overrideGuard, overrideInterceptor, etc.
@ogbuezekiel74002 жыл бұрын
Please can you share your code or repo Thanks. Your content is amazing
@danielguldbergaaes64322 жыл бұрын
@Marius you can simply configure jest to use the same import strategy as vs code with the following config ``` "jest": { "moduleFileExtensions": [ "js", "json", "ts" ], "rootDir": "./", "modulePaths": [ "" ], "testRegex": "spec.ts$", "transform": { "^.+\\.(t|j)s$": "ts-jest" }, "collectCoverageFrom": [ "**/*.(t|j)s" ], "coverageDirectory": "../coverage", "testEnvironment": "node" } ```
@mariusespejo
2 жыл бұрын
Ahh thanks for the tip!
@danielguldbergaaes6432
2 жыл бұрын
@@mariusespejo your welcome :)
@danielguldbergaaes6432
2 жыл бұрын
@@mariusespejo Btw, have you found a way to use a vscode plugin to run the test? I would love to have a better interface for reviewing the test and see what values was returned and so on.
@mariusespejo
2 жыл бұрын
There is a jest vs code extension that I tried before that can do something like that but I wasn’t a fan of it. If you google vs code jest it’ll be the first result
@danielguldbergaaes6432
2 жыл бұрын
@@mariusespejo I also tried that one out, but it is pretty slow compared to just using the cli tool, I was hoping I had missed some gold right in front of my eyes :)
@user-ez6xb3rf3p3 жыл бұрын
Great
@brendon2052 жыл бұрын
You were making integration tests but the file names had "end to end" is that right? I know it's just the name, but it confuses me a little bit 😆
@mariusespejo
2 жыл бұрын
technically speaking e2e IS an integration test, it just happens to to cover the entire flow end to end like from a user’s perspective them making a request and getting a response back
@alanrodriguezw.91493 жыл бұрын
Thanks You! Very Helful.
@antoniosousa417819 күн бұрын
e2e is equal/same to integration test?
@mariusespejo
14 күн бұрын
E2e is an integration test, but an integration test doesn’t always need to be end-to-end if that makes sense
@alexanderzharkov69533 жыл бұрын
That was really helpful for me. I discovered so many things about testing and now feel like I'm ready to write these tests. I have a question: what code editor theme have you been using during this video? ;) Isn't the Night owl?
@mariusespejo
3 жыл бұрын
glad to hear! yep it is night owl 🦉 Also have been trying github dark in some of my newer vids
@atilaaugusto_3 жыл бұрын
great content!
@mariusespejo
3 жыл бұрын
thanks!!
@raikiri-f2m Жыл бұрын
Holy cow! its too good lecture. And I have a question. I am trying to do integration test. And my modules use axios. And then I got error which indicates that jest cannot parse axios. Can you give some suggestions on this ?
@mariusespejo
Жыл бұрын
Nest has an HTTP module @nestjs/axios which basically lightly wraps axios and you make requests via HttpService, meaning it’s something injected and can be easily mocked in tests. Anything that you use directly will be slightly harder to mock unless you want to mock it at the jest level (which can also do its own module mocking) vs at the nest level
@rohmatmret82653 жыл бұрын
can you share code in github ..?
@ivanmiarkulau83203 жыл бұрын
thanks a lot for this guide!
@mariusespejo
3 жыл бұрын
glad to help!
@igortrifonov93392 жыл бұрын
thanks for a video!
@creative-commons-videos3 жыл бұрын
does this testing work same for both REST and GraphQL endpoints ?
@mariusespejo
3 жыл бұрын
yes should be mostly the same concepts for graphql endpoints but the key difference is for your e2e tests they will always be a POST with a request body containing the query
@niel_morphius2 жыл бұрын
Great tutorial, really helped me with mocking my repository on the test file. I have really been struggling with it. I have a question though. How do I override a guard in my controller and also override a provider at the same time. I tried .overrideProvider().overrideGuards() but it didn't work and I kept getting the error "Property 'overrideProvider' does not exist on type 'OverrideBy'.". I would really appreciate your guidance on how to go about it. Thank you
@mariusespejo
2 жыл бұрын
You missing a few things there, you need to do something like this: .overrideProvider(MyService).useValue(myServiceMock).overrideGuard(MyGaurd).useValue(myGuardMock) Basically you need to tell it HOW to do the override. I think there is also .useClass() as an alternative to useValue() if your mock is a class and not an instance/object
@niel_morphius
2 жыл бұрын
@@mariusespejo worked like a charm. Thanks alot, you literally saved the day 😅
@mariusespejo
2 жыл бұрын
Great!!
@AliAliOxenFree Жыл бұрын
Great video buddy. I wrote my first unit test for one endpoint in a pretty fleshed out backend API, and it was over 136 lines long. Is that normal? I imagine that if i do the rest of the endpoints in the controller file it will reach to 500 lines-ish
@mariusespejo
Жыл бұрын
A controller unit test generally should be short. Most of your business logic should be in services/providers meaning a controller should be pretty slim and unit tests of it in most cases just need to assert that it’s calling the right service methods (which can be mocked). The endpoint e2e tests I would expect to be quite a bit longer because you’re integrating all the things including authentication, authorization, validation, middlewares, then finally asserting expected status codes and body response, etc. The e2e test is where you’ll get the most value, specially if you keep mocks to a minimum
@AliAliOxenFree
Жыл бұрын
@@mariusespejo thanks for the thoughtful response. I'll revisit the code and maybe try to get rid of sections. It makes sense as the controller only handles requests/responses.
@alessandrorhomberg53663 жыл бұрын
It would be nice to have a tutroial about NestJS Authentication, Authorization (Claims-based authorization) :)
@mariusespejo
3 жыл бұрын
I do have one for authentication in my channel
@alessandrorhomberg5366
3 жыл бұрын
@@mariusespejo I've already seen a really good tutorial. Would be cool if you went even more deeply into the subject of authentification and authorization. like RBAC and CASL
@ta3113ta3 жыл бұрын
thank you so much.
@bossmusa9075 Жыл бұрын
why are we doing this? Like we anyways implemented fake function and will implement functional in service that will contain bugs
@mariusespejo
Жыл бұрын
You might be mocking the dependencies but you’re still testing that the logic in your functions are producing the intended results. The examples here might be too simple to fully see the value of it, I was mostly showing the HOW but I recommend reading about the WHY
@bossmusa9075
Жыл бұрын
@@mariusespejo okay thanks
@user-yu8lk3eh1i3 жыл бұрын
Very useful video, can you provide git repo
@istbanane3 жыл бұрын
Is it possible to test the API with the database? Probably with e2e?
@mariusespejo
3 жыл бұрын
yeah I don’t see why not. You might want to use something that’s in memory though like sqlite or something and you’ll need to make sure the database is wiped for each test. You likely will also need to migrate and/or seed per test.
@istbanane
3 жыл бұрын
@@mariusespejo Thank you very much. The videos are great.
@ahheask95275 ай бұрын
Have source code in github?
@AliHaider-ep1hy Жыл бұрын
can i have the link to your github repo??
@joaquinsarmiento73612 жыл бұрын
Is this a junior, mid or senior tutorial?
@mariusespejo
2 жыл бұрын
Are you asking about dev titles? Those honestly don’t mean anything in terms of your ability to learn
@alexandercuartas8303 жыл бұрын
Yo, thanks a lot for the video
@mariusespejo
3 жыл бұрын
no probs!
@DodaGarcia3 жыл бұрын
I'm having that same problem with the autoimport!! It's a pain
@DodaGarcia
3 жыл бұрын
That said, E2E tests aren't usually meant to use a mock repository, but a fully provisioned test version of it that's as close to the production setup as possible. I started working with NestJs very recently and love how it keeps the code organized, but it's not very helpful in creating integration tests, only unit (total isolation) and E2E (close to production). I supposed E2E tests do technically count as integration tests though, so it's not a huge deal either.
@mariusespejo
3 жыл бұрын
Yeah I would consider e2e as integration. Also you can run e2e tests with an actual db if you really wanted to, e.g. a sqlite for example, but you’d have to migrate/seed and wipe the db before/after each test. That added overhead/complexity may or may not be worth it depending on your use case or preference
@auinspiration03 Жыл бұрын
please provide this video git Repo for more understanding
@stephenkamenar Жыл бұрын
if you're making a mock service that has fake methods. what are you even testing? how is this useful?
@mariusespejo
Жыл бұрын
Well the point of unit tests is to isolate and typically provide mock dependencies. Is it able to function in isolation? I’m just explaining how to do it. Whether or not that’s useful to you is up to you. But it’s the entire point of dependency injection, to be able to easily inject alternative dependencies (e.g. mocks in this case) I do think the e2e tests are where most of the value is, specially if you minimize mocks and setup a real db so that you don’t have to mock the queries. But you need a little bit more setup for that, e.g. you need to be able to reset your database for each test. How much you actually mock is ultimately up to you, e.g. how much of a unit vs integration test do you want to do.
@Cognitoman Жыл бұрын
Yo
@mariusespejo
Жыл бұрын
Sup
@Cognitoman
Жыл бұрын
@@mariusespejo I don’t know about testing, should you be doing end to end testing with unit testing ?
@user-pe5qr2wp4u2 жыл бұрын
useless without code//
@mariusespejo
2 жыл бұрын
You mean the code that’s recorded? Lol
@khoaha3483 Жыл бұрын
PASS src/modules/users/controllers/users.controll.spec.ts ● Console console.log debug: Logging initialized at debug level {"timestamp":"10-02-2023 13:00:10"} at Console.log (node_modules/winston/lib/winston/transports/console.js:79:23) at async Promise.all (index 4) at async Promise.all (index 9) my app when I running test. its pass the test but it not log the test text. can you help me.
Пікірлер: 178
Your Nest videos are easily the best I've seen. Could you do another one on testing where you set up a Development database using migrations, and then only do E2E testing with the database as a part of the testing.
@mariusespejo
3 жыл бұрын
thanks! you’re thinking like a true full e2e where it actually writes to a db instead of mocking it out? Sure I can potentially make something for that
@jon1867
3 жыл бұрын
@@mariusespejo I would absolutely love that. I spent my day setting up a docker and figuring out how to use a node environment to choose which one to spin up upon test. But I've been having a hell of a time with jest dependencies being all messed up for some reason. I appreciate you!
Brother, you are a life savior. I look for many resources but couldn't find that overriding thing. Thanks so much, brother 😁👍👍 Subs to your channel
@mariusespejo
3 жыл бұрын
Awesome glad to help, thanks!
Great introduction. I've been banging my head trying to get mocking to work while using typeDI and typeORM. Might just switch my whole backend to use NestJS after watching this =)
@mariusespejo
3 жыл бұрын
great! I haven’t tried typeDI but if you’re definitely looking for a DI-based framework you can’t go wrong with nest, and it’s got great integration with typeorm so you’re also covered there
great work, very well explained. greetings from Argentina 🔵⚪🔵
More great content. The music is cool and soothing to start, and glad you dropped it as the 'real' content started. :)
@mariusespejo
2 жыл бұрын
Thanks! I mostly don’t add music in newer stuff, there’s a thin line between it being entertaining and potentially distracting
thanks for awesome tutorial video, watching your video with speed 1.5 is always my way for running through all of it then begin to coding :)))
@mariusespejo
Жыл бұрын
Glad to know you can still understand me at 1.5x haha thanks!
Crystal clear as usual, Great video Marius!
I really miss git repository here :( Sometimes when you want to jump from file to file its really difficult to switch between different timestamps in video.
@mariusespejo
2 жыл бұрын
thanks for you input, I do need to work on providing source code along with the content
@MrBadsectorr
2 жыл бұрын
@@mariusespejo that would be greatly appreciated :)
Dude, you rock! Congratulations for your amazing work :)
Hey, I am looking for a setup for test suites in NestJS, but with addition of factories for classes, in order to help me with seeding and "Arrange" Step of the Test. Any idea where to watch that? Especially, for complex schemas where i.e. I want to test a module, which every entity depends on the creation of others.
Great tutorial. Your efforts is truly appreciated
@mariusespejo
2 жыл бұрын
Thank you!
Thank you, the unit test part was perfect, the e2e I would prefer not mocking anything, but thanks anyway for the good content
@mariusespejo
Ай бұрын
Yup I actually agree, overtime I’ve found it better to actually just run tests off of a real database to get e2e as close to real as possible, but it does require a little extra setup. thanks for stopping by to comment!
@Marius Espejo, how to override multiple services in createTestingModule? My controller A is dependent on service B,C,D
Great content you've provided here sir! Just wanna leave a quick note that if you've created a custom class for your Repository you'll have to write "provide: UserRepository," instead of "provide: getRepositoryToken(User)," Keep up the good work!
@mariusespejo
3 жыл бұрын
thanks Anderson! good note, I haven’t actually tried making a custom class for repositories yet, will take a look at that
Thanks a lot tried clicking the subscribe button to subscribe twice...
thank you so much, you've put everything on the shelves.
@mariusespejo
2 жыл бұрын
You're welcome!
any chance of the starter code so people can follow quickly without much set up
so clear, Thank you so much would like to see more of these.
@mariusespejo
3 жыл бұрын
thanks Tushar! definitely more of these in the future. Anything specific you were hoping to be covered?
@tusharroy6182
3 жыл бұрын
@@mariusespejo A Project! I would be happy if you can build a project connecting all the topics that you have covered so far. Would be really awesome to see how these things work together. Thanks
Really helpful tutorial, clear and straight forward. Thanks much!
How to do e2e test on getManager().query(). While doing so, it always takes default connection
Hello, I have tried to do the video, but I try to connect to the DB all the time... my way is to simulate the service call, that
Hey! thanks for the video!. Im trying to create test filed on an existing project, npx nest generate test place, place being the name of the module i want to test. I get "Invalid schematic "test". Please, ensure that "test" exists in this collection.". :/ Do i need to install it separately?
@mariusespejo
Жыл бұрын
Invalid schematic means it’s not supported for generate, you’ll just have to make the file manually.
Hi Marius! Question, should we always create a unit test for our service? Or should we just create an integrarion test? I want my test no to be related to the implementation only on the output of the service. What do uou think?
@mariusespejo
6 ай бұрын
Having a mix of both is good but whether or not you should always do unit tests is up to you. If you had to pick one to focus on, definitely the integration tests are more valuable.
Yes for the end to end test so that your E2E tests act as a living documentation . Thanks
Hi Marius, following your video (e2e testing), I keep getting this error: Nest can't resolve dependencies of the JwtStrategy (AuthService, ?). Please make sure that the argument ConfigService at index [1] is available in the AuthModule context. I tried the overrideProvider for ConfigService, but no hope. Any ideas? Thank you
@mariusespejo
2 жыл бұрын
That means you didn’t register the config module in your auth module. Alternatively you can register it globally docs.nestjs.com/techniques/configuration#use-module-globally
@ahmedjumaah9727
2 жыл бұрын
@@mariusespejo It is registered globally in the appModule. I added it into the authModule and now I get: Nest can't resolve dependencies of the UserModel (?). Please make sure that the argument DatabaseConnection at index [0] is available in the MongooseModule context.
@mariusespejo
2 жыл бұрын
I mean it’s telling you exactly what the problem is, the module you’re trying to use is missing dependencies. In a test not all of your modules are necessarily registered like in the real app, so it’s not able to find things. That means in your test you either need to add those missing dependencies in the test module, or you need to mock them
@ahmedjumaah9727
2 жыл бұрын
@@mariusespejo Hi again, I resolved it by mocking configService. Thanks man :)
@mariusespejo
2 жыл бұрын
Glad you got it figured out!
Lovely tutorial
You saved my day. Thank you.
Great Video
@27:40 integration tests begins
You saved my day, thank you.
Hey man, in the first test example, how can I test if my validation with class-validator are working? example: test if my response have a status code of 400 if no nome is provided, if the message contain "no name provided"? I'm trying this, but I don't know how :(
@mariusespejo
Жыл бұрын
I actually did cover exactly how to do that in the video towards the end, make sure to watch the whole thing 🙂
you are the best!, thank you!
@mariusespejo
2 жыл бұрын
You’re welcome!
on the service tests, your mock implementation of create() is not creating an id. i don't know why the test of it passes.
@mariusespejo
Жыл бұрын
Create() doesn’t create the ID, the save does (which is where inserting would actually happen). And you should notice that the save mock does have ID creation in it. That’s why the test passes
Thank you kindly for this video.
Easy and helpful
Amazing Video!
Excellent tutorial. where were you 1 year ago? I had to learn testing the hard way.
@mariusespejo
3 жыл бұрын
A year ago? likely being a bum and not making videos haha glad it helped you!
Great content.
Great tutorial. and can you put repo link please to make it doc for me ?
Thanks man ... really nice groundwork for us to build on top. I'm enjoying myself doing some old school TDD (is this still a thing?) on an idea I'm having and one thing I'm trying to achieve is that in the name of the technique, iow the unit tests should drive how I design my units and the integration tests how I design my integrations. At the 27min mark, there is a comment on changes impacting the test code ... but wouldn't that be exactly the reason why you are writing them? I mean, you want to have an asset that tells you if any of the changes performed in your existing code base is breaking it, also, if the tests should be driving the design, then I would think it's a good idea to write them first and let them fail, then your redesign now has a very concrete objective, to pass the tests. This has limitations but seems pretty fun to do and makes writing tests much less cumbersome (and with a slight lesser feeling of worthlessness?) and one I can tell right away is that it should not dictate how the unit being tested will work, but instead rely on testing its Inputs and Outputs (Black Box Testing).
@mariusespejo
2 жыл бұрын
Yeah some good points. Yes in general your tests should act as a safety net to capture any moment that you MIGHT have broken previous functionality. That is precisely the purpose of tests. However IDEALY your tests should not simply be a mirror of your exact implementation details. If I have a test that asserts something is created, it shouldn’t matter exactly HOW it was created. Otherwise you’re really just testing implementation details and that leads to brittle tests. That’s the point I was trying to make around the 26:50-27min mark, that in ideal terms I should be able to change the underlying query but as long as it still results in the same expected result, then my test should pass. That’s basically what you pointed out with black box testing so I’m not sure where the disconnect is, it sounds like we agree on the same core principle. However I was calling it out specifically because at that example unit test, if you mock the dependency, it’s a bit hard to create a mock that doesn’t ultimately behave or mirror your implementation details. Also this video was really more a lesson on how to setup tests for Nest specifically and not necessarily on TDD. However I actually do think TDD is a great practice, in general anything that promotes designing the API first in some way is a good thing
@acommunistdwarf
2 жыл бұрын
@@mariusespejo thanks for the answer man, no disagreement indeed, I just fell the need to get that point you made and bring the TDD talk. Thanks again for the video man, much success!
Could you suggest a clean way of how test db should be configured for tests. Sould entire database module be mocked, or just configuration file changed, or environment. How migration and seeds should be implemented. Maybe you know great article about all of this?
@mariusespejo
11 ай бұрын
It depends entirely on how “real” you want it to be. You could literally spin up a database like mysql/postgres with docker for example and set it up in such a way that it starts fresh per test. Run migrations, seed data, trigger your queries and make your assertions, wipe the db, rinse repeat. But the tradeoff is complexity and tests running slower. It’s also more complex doing that on CI, depending on your setup. Next best thing, maybe the same thing but run sqlite in memory. Tradeoff is that if you’re not actually using sqlite in production then there are API and behavior differences compared to your real DB. Next option is mocking the database layer entirely, perhaps at the ORM level. It’s easier, you don’t have to deal with migrations, tests are quick. But the tradeoff is your tests are the farthest away from being “real”. So it all boils down to how much confidence do you want your tests to produce and how complex of a setup are you willing to put up with
Hello Marius, Great tutorial.
@mariusespejo
2 жыл бұрын
Hello! Glad you liked it!
Great video man, but I have a problem, I have a folder with multiples resources into, this called, phase-two, when I try to run any test file, doesn't work, show me a message about the Service Name can't be found it and other stuff. On the other hand, the first phase, called phase-one, doesn't have any issue, but in this folder the module is a same level of the test file generate by Nest. Do you know any solution for that?
@mariusespejo
2 жыл бұрын
Generally in tests if it says it can’t find a dependency it’s because you test module didn’t include it (or a mock of it) so it doesn’t know what to inject, hence it will say can’t be found
@PterPmntaM
2 жыл бұрын
@@mariusespejo Thanks, I found a video where solved that problem.
Lovely video. Thanks A Lot
@mariusespejo
3 жыл бұрын
thanks! 🙏 glad you like it
Thank you! This helped me a lot!
@mariusespejo
Жыл бұрын
Glad it helped!
Great content, and if I have logic in my service layer that can return errors like 404, 409, how do I test this in the controller and service layer?
@mariusespejo
Жыл бұрын
Lets say for example your service layer throws “EntityNotFound” which the controller catches so it can then throw NotFoundException. Then in your controller unit test the service mock for one of your tests bust be setup to throw EntityNotFound, then you can assert NotFoundException was thrown. Similar idea for the service. If you were doing an e2e test then similar idea but instead you’d actually assert that you got a 404 status response. Hope that helps
GREAT. NICE JOB!!!
Thank you very much, it helped a lot!
Excellent video, love the way you explain things. So simplified, easy to go through and grasp knowledge. Have you consider doing Udemy courses? Cause I strongly believe people would like to aquire more depful content from you.
@mariusespejo
2 жыл бұрын
Yeah I’ve thought about making paid courses, but for now it’s all just here for free :)
27:10 One comment about the 'expect().toBeCalled()' assertions making the tests brittle. They already *are* brittle, because you are implicitly relying on the underlying implementation in your choice of which methods to define in your mockUserRepostory. For example, if you switched to using insert() and query() in the service, your mockUserRepository probably wouldn't have those methods defined, so the test would fail anyway. For a real life project, I am needing to effectively mock a lot of prisma in this manner. I'd also potentially like to be able to inject different provider overrides for different tests: any ideas how? Great tutorial though, thanks.
@mariusespejo
2 жыл бұрын
Fair enough good point! I feel like mocking ORM/query builders in general always leads to that. I think the only way to get around that is by having an extra layer of abstraction so that you’re not dealing with the underlying implementation directly. E.g. for typeorm for example you can do custom repositories: orkhan.gitbook.io/typeorm/docs/custom-repository I imagine that would result in just needing to mock a single method from the repo. As for your override question, you can maybe use multiple describe blocks with their own test beds for each set of tests with different overrides. Not sure there’s a better way than that
@stainlesssteellemming3885
2 жыл бұрын
@@mariusespejo Thanks. And, of course, this is true of any dependency mocking. You try and mock the smallest part of the dependency's interface, but that means understanding the implementation details of the code under test. Eventually, you need a test suite to check that the mock implementation works correctly.
In unit test, I saw that mostly we mock everything just to get the expected result, but if we mock something it for sure to be an expected result right ? I am curious let say in my service method contains some logic, how will this code be tested ? or is that we dont really need to test it ? most of unit testing video/ tutorial only showthe case where the service method that is simple, like have single line of code and mock dependency method that being called. What if I have a service method as below logic(input): { // do something with input example data transformation return input.toUpperCase(); } when we write expect(service.logic(input)).toEqual(expectedResult); is that method really executed ? meaning it really call the exact service.logic method and return an upper case of the input ?
@mariusespejo
3 жыл бұрын
We mock the dependencies but not the actual underlying logic of the thing your testing. In your example you’d unit the service by making sure that the output is transformed, your example would require zero mocking. But let’s say it uses a repository to select the input from the database, then your service logic uppercases it prior to returning, then your mock repository should return some mock return value and you would assert that you not only got the mock value but also that it’s all uppercase
Great video! Any idea on how to mock a request session using supertest? My controller pulls data off of the request session. I'd like to be able to mock that in my e2e test
@mariusespejo
2 жыл бұрын
In theory you just need a mock middleware which puts data inside req.session, and that data could be whatever you want. Or otherwise maybe you could mock other parts of the pipeline, e.g. if you had a guard that checks data in session, you could mock that guard instead
do you have an example using prism?
AWESOME VIDEO, THANK YOU SO MUCH! subscribed also
@mariusespejo
3 жыл бұрын
thanks! 🙌
Very nice!
Thanks what are your thoughts on testing the typeorm entities? How do we test db constraints in entity or add validation at entity level using class validator?
@mariusespejo
3 жыл бұрын
You’re meant to utilize class validator on the dto not the entity, because you’re validating the data that’s coming in from a client not data coming out of the db which is what the entity classes represent. You can involve a real in-memory db if you wanted to but I don’t really see a ton of value in testing db constraints, it’s not your job to verify that the database is working as it’s supposed to. However that’s not to say that testing the integration with a real db is useless, there is value in doing a true end-to-end integration test. But the point is to test the integration not the individual database constraints
VS Code TS Auto-Import setting in preferences: Typescript > Preferences > Import Module Specifier. :)
@mariusespejo
2 жыл бұрын
Ah thanks didn’t know there was setting for that lol
@JustinMorganYXX
2 жыл бұрын
@@mariusespejo I coincidentally had the same issue this week. Glad I could help.
perfect man
nice explanation. How would you approach testing endpoints that have guards / decorators and interceptors etc..
@mariusespejo
3 жыл бұрын
I would test them as usual and have those things run for real. However it depends on the underlying implementation behind those decorators. For example if you have an auth guard that integrates with an external identity provider, then I would either mock that guard or use a different passport strategy specifically for testing. RBAC guards I would definitely try to test for real, but that’s where your auth mock will come into play (e.g simulating different users with different roles). If you do need to mock any of it, there’s a small detail in the video where I briefly show that you can also do things like overrideGuard, overrideInterceptor, etc.
Please can you share your code or repo Thanks. Your content is amazing
@Marius you can simply configure jest to use the same import strategy as vs code with the following config ``` "jest": { "moduleFileExtensions": [ "js", "json", "ts" ], "rootDir": "./", "modulePaths": [ "" ], "testRegex": "spec.ts$", "transform": { "^.+\\.(t|j)s$": "ts-jest" }, "collectCoverageFrom": [ "**/*.(t|j)s" ], "coverageDirectory": "../coverage", "testEnvironment": "node" } ```
@mariusespejo
2 жыл бұрын
Ahh thanks for the tip!
@danielguldbergaaes6432
2 жыл бұрын
@@mariusespejo your welcome :)
@danielguldbergaaes6432
2 жыл бұрын
@@mariusespejo Btw, have you found a way to use a vscode plugin to run the test? I would love to have a better interface for reviewing the test and see what values was returned and so on.
@mariusespejo
2 жыл бұрын
There is a jest vs code extension that I tried before that can do something like that but I wasn’t a fan of it. If you google vs code jest it’ll be the first result
@danielguldbergaaes6432
2 жыл бұрын
@@mariusespejo I also tried that one out, but it is pretty slow compared to just using the cli tool, I was hoping I had missed some gold right in front of my eyes :)
Great
You were making integration tests but the file names had "end to end" is that right? I know it's just the name, but it confuses me a little bit 😆
@mariusespejo
2 жыл бұрын
technically speaking e2e IS an integration test, it just happens to to cover the entire flow end to end like from a user’s perspective them making a request and getting a response back
Thanks You! Very Helful.
e2e is equal/same to integration test?
@mariusespejo
14 күн бұрын
E2e is an integration test, but an integration test doesn’t always need to be end-to-end if that makes sense
That was really helpful for me. I discovered so many things about testing and now feel like I'm ready to write these tests. I have a question: what code editor theme have you been using during this video? ;) Isn't the Night owl?
@mariusespejo
3 жыл бұрын
glad to hear! yep it is night owl 🦉 Also have been trying github dark in some of my newer vids
great content!
@mariusespejo
3 жыл бұрын
thanks!!
Holy cow! its too good lecture. And I have a question. I am trying to do integration test. And my modules use axios. And then I got error which indicates that jest cannot parse axios. Can you give some suggestions on this ?
@mariusespejo
Жыл бұрын
Nest has an HTTP module @nestjs/axios which basically lightly wraps axios and you make requests via HttpService, meaning it’s something injected and can be easily mocked in tests. Anything that you use directly will be slightly harder to mock unless you want to mock it at the jest level (which can also do its own module mocking) vs at the nest level
can you share code in github ..?
thanks a lot for this guide!
@mariusespejo
3 жыл бұрын
glad to help!
thanks for a video!
does this testing work same for both REST and GraphQL endpoints ?
@mariusespejo
3 жыл бұрын
yes should be mostly the same concepts for graphql endpoints but the key difference is for your e2e tests they will always be a POST with a request body containing the query
Great tutorial, really helped me with mocking my repository on the test file. I have really been struggling with it. I have a question though. How do I override a guard in my controller and also override a provider at the same time. I tried .overrideProvider().overrideGuards() but it didn't work and I kept getting the error "Property 'overrideProvider' does not exist on type 'OverrideBy'.". I would really appreciate your guidance on how to go about it. Thank you
@mariusespejo
2 жыл бұрын
You missing a few things there, you need to do something like this: .overrideProvider(MyService).useValue(myServiceMock).overrideGuard(MyGaurd).useValue(myGuardMock) Basically you need to tell it HOW to do the override. I think there is also .useClass() as an alternative to useValue() if your mock is a class and not an instance/object
@niel_morphius
2 жыл бұрын
@@mariusespejo worked like a charm. Thanks alot, you literally saved the day 😅
@mariusespejo
2 жыл бұрын
Great!!
Great video buddy. I wrote my first unit test for one endpoint in a pretty fleshed out backend API, and it was over 136 lines long. Is that normal? I imagine that if i do the rest of the endpoints in the controller file it will reach to 500 lines-ish
@mariusespejo
Жыл бұрын
A controller unit test generally should be short. Most of your business logic should be in services/providers meaning a controller should be pretty slim and unit tests of it in most cases just need to assert that it’s calling the right service methods (which can be mocked). The endpoint e2e tests I would expect to be quite a bit longer because you’re integrating all the things including authentication, authorization, validation, middlewares, then finally asserting expected status codes and body response, etc. The e2e test is where you’ll get the most value, specially if you keep mocks to a minimum
@AliAliOxenFree
Жыл бұрын
@@mariusespejo thanks for the thoughtful response. I'll revisit the code and maybe try to get rid of sections. It makes sense as the controller only handles requests/responses.
It would be nice to have a tutroial about NestJS Authentication, Authorization (Claims-based authorization) :)
@mariusespejo
3 жыл бұрын
I do have one for authentication in my channel
@alessandrorhomberg5366
3 жыл бұрын
@@mariusespejo I've already seen a really good tutorial. Would be cool if you went even more deeply into the subject of authentification and authorization. like RBAC and CASL
thank you so much.
why are we doing this? Like we anyways implemented fake function and will implement functional in service that will contain bugs
@mariusespejo
Жыл бұрын
You might be mocking the dependencies but you’re still testing that the logic in your functions are producing the intended results. The examples here might be too simple to fully see the value of it, I was mostly showing the HOW but I recommend reading about the WHY
@bossmusa9075
Жыл бұрын
@@mariusespejo okay thanks
Very useful video, can you provide git repo
Is it possible to test the API with the database? Probably with e2e?
@mariusespejo
3 жыл бұрын
yeah I don’t see why not. You might want to use something that’s in memory though like sqlite or something and you’ll need to make sure the database is wiped for each test. You likely will also need to migrate and/or seed per test.
@istbanane
3 жыл бұрын
@@mariusespejo Thank you very much. The videos are great.
Have source code in github?
can i have the link to your github repo??
Is this a junior, mid or senior tutorial?
@mariusespejo
2 жыл бұрын
Are you asking about dev titles? Those honestly don’t mean anything in terms of your ability to learn
Yo, thanks a lot for the video
@mariusespejo
3 жыл бұрын
no probs!
I'm having that same problem with the autoimport!! It's a pain
@DodaGarcia
3 жыл бұрын
That said, E2E tests aren't usually meant to use a mock repository, but a fully provisioned test version of it that's as close to the production setup as possible. I started working with NestJs very recently and love how it keeps the code organized, but it's not very helpful in creating integration tests, only unit (total isolation) and E2E (close to production). I supposed E2E tests do technically count as integration tests though, so it's not a huge deal either.
@mariusespejo
3 жыл бұрын
Yeah I would consider e2e as integration. Also you can run e2e tests with an actual db if you really wanted to, e.g. a sqlite for example, but you’d have to migrate/seed and wipe the db before/after each test. That added overhead/complexity may or may not be worth it depending on your use case or preference
please provide this video git Repo for more understanding
if you're making a mock service that has fake methods. what are you even testing? how is this useful?
@mariusespejo
Жыл бұрын
Well the point of unit tests is to isolate and typically provide mock dependencies. Is it able to function in isolation? I’m just explaining how to do it. Whether or not that’s useful to you is up to you. But it’s the entire point of dependency injection, to be able to easily inject alternative dependencies (e.g. mocks in this case) I do think the e2e tests are where most of the value is, specially if you minimize mocks and setup a real db so that you don’t have to mock the queries. But you need a little bit more setup for that, e.g. you need to be able to reset your database for each test. How much you actually mock is ultimately up to you, e.g. how much of a unit vs integration test do you want to do.
Yo
@mariusespejo
Жыл бұрын
Sup
@Cognitoman
Жыл бұрын
@@mariusespejo I don’t know about testing, should you be doing end to end testing with unit testing ?
useless without code//
@mariusespejo
2 жыл бұрын
You mean the code that’s recorded? Lol
PASS src/modules/users/controllers/users.controll.spec.ts ● Console console.log debug: Logging initialized at debug level {"timestamp":"10-02-2023 13:00:10"} at Console.log (node_modules/winston/lib/winston/transports/console.js:79:23) at async Promise.all (index 4) at async Promise.all (index 9) my app when I running test. its pass the test but it not log the test text. can you help me.