NodeJS Express Test-Driven API Development (TDD)
ฝัง
- เผยแพร่เมื่อ 2 เม.ย. 2021
- In this video we learn about the basics of Test-Driven Development (TDD) specifically in the landscape of developing APIs. We use ExpressJS, Jest, and supertest as our frameworks of choice here, but the fundamentals that you learn from this video can be applied in almost any scenario, regardless of what NodeJS or testing framework you are using.
![Typescript API in NodeJS / Express in Depth [Part 1]](/img/n.gif)
hey folks, something I should clarify: the takeaway here is NOT necessarily that you write ALL tests at once. It should be an iterative process of writing tests, implementing, refactoring... rinse repeat. That iterative process isn’t necessarily shown in this video so it might be misleading to some. I simply started with writing tests for the requirements I already had/defined at hand. For some people it might be more like writing those tests one at a time and being more iterative. Hope that clarifies things!
Hi. What do you think of prisma vs typeorm ? Which is best suited for nestjs?
hey George, you might be commenting on the wrong video, but anyways prisma vs typeorm is something I can’t really explain well in a comment. Perhaps maybe in a future video. However some quick things: Prisma works at a higher abstraction, has better type safety in some cases, and requires defining a dedicated schema file. Typeorm on the other hand simply provides an API for sql operations and prefers classes with decorated fields (which you already see a lot of in Nest, so I would argue by nature it fits better). Also you’ll see in the Nest docs that it believes TypeORM is the most mature ORM for TS apps, so I think there’s a clear bias there from Nest creators itself. End of the day though, they’re different tools for solving the same problems, it’s really up to your preference!
This is what I have been looking for, great video.
Awesome! I like your way of explaining, clean and clear, cannot wait for another great content ❤️
Happy to hear that! thank you!
Fast and crystal clear. Thank you.
Brilliant! Very useful. Got me started on TDD
I do not know why this video has less then 100K views . Really amazing Content and TDD really well explained . Thanks .
Excellent Marius, this video helped me a lot in recognition TDD idea and how to use it in nodejs environment ♥
thanks Marius i got a lot better understanding of TDD thanks to your video....
Really helpful man, thank you. All the tutorials I used to learn how to code never mentioned tests... then I find out I'm a complete noob for not using TDD
I wouldn’t say you’re a noob for not doing TDD, honestly most people would typically write tests after the implementation. I would maybe consider it more a preference/strategy.
In general as long as you’re writing tests for your code that’s an absolute must for production work, wether you do it before or after is up to you. Doing it before however guarantees that it’s not something you forget about, it’s what drives the whole development
Thanks, this is very clear and helpful!
Very well explained. Thanks for the video.
This has been explained beautifully.
thanks for sharing this video. clearly explained.
Thank you so much for this video.
Thanks for sharing such a good content. It helped me a lot.
Galing sir! nahanap ko din to
Thanks! Hoping to see more fundamentals videos. Maybe something on load time and request calls
will take note of those, thanks!
Great video, thanks! BTW Marius is a strong name.
This is awesome, I have learned a lot. I was trying to implement Async Await as well but I couldn't achieve it. Any suggestions?
Nice video! I'm going to google how to create multiple files. I want to see how it scales when you have tons of tests
excellent video!
thank you so much this was awesome!
you’re welcome!
nice bro !!! thanx .. please more content node express and Redux
Sure thing!
Very clear tutorial
Thanks!
Thanks you !
11 out of 10 for testing video
Thank you so much
you’re welcome!
Thanks helped a lot ! Just curious what extensions do you use in vs code?
Just the typical ones, eslint, prettier, gitlens, various ones for different tech like snippets for react, stuff for markdown, etc.. too many to list in a comment. Did something catch your eye in the video?
I've seen some examples on MERN project and they seem to mainly just check the status code. Whereas in your example, you're checking for much more things per each request, like the structure (array) of data returned, the type of values within objects etc. Which way is preferred?
I kind of see as: tests should give you confidence to refactor your code, basically informs you if you broke something. If you're only checking for status code then it's not verifying that it's still returning the same data structure (if you were to refactor). To me personally status code alone would not be enough
Thanks, great example in making it simple by using a Todo list, unlike other tutorials that use complicated examples like authentication.
So when testing post requests, we need to be aware that they can alter the database so the only real way to test them is to create a mock database right?
Yeah pretty much either mock it or use an in-memory one just for tests however that adds a bit of overhead to setup
@@mariusespejo Is it common for backends in actual companies to not mock the DB in fear of excess complexity? If so then how do you test for requests that update the DB that alter its table?
Every company and even every team is different I couldn’t tell you what’s common. But I would say it’s about fear, it’s about cost and tradeoffs. For example let’s say you wanted to use an in-memory database, typical choice for that is sqlite. However sqlite does not have 100% compatibility with real databases like myql and postgres, so you might end up having some hacks just to get stuff to work for tests. You also have to think about the fact that ideally your tests are isolated from each other, that means you’d have to clear the database, migrate, seed it… over and over again. You can also choose to use a real database, perhaps a non-prod replica of some sort, and just make sure to delete data your test added… again in any direction even with mocking there is a level of complexity or overhead, it’s up to you and your team to decide what tradeoffs you’re willing to make.
Hi Marius, excellent video. Do you have the repository for the code somewhere to access?
Ah sorry not at the moment
Cool. But in real-world application we have DB and API calls. How we should deal with them in tests?
you can either mock those calls or have a real in memory database that you make queries to
Is it worth learning Nestjs, I mean from a career point of view are companies adopting to it ? or is it the one more JS framework ??
It’s popular but it’s not the only one. Learn your fundamentals and you should be able to switch to whatever frameworks your company uses
how to get that '-->' same as yours ?? it is different in mine
not sure what you mean, like in the test message? it’s literally just dash dash chevron, nothing fancy
Hey Which Code formatter are you using ?
I use and suggest prettier for pretty much any JS project
Write production code only to pass a failing unit test.
Write no more of a unit test than sufficient to fail (compilation failures are failures).
Write no more production code than necessary to pass the one failing unit test.
When I see or hear "lets build a todo.... " I close the tab
Such a narrow viewpoint lol It’s about the underlying concepts and fundamentals, e.g. with this one TDD and API development, not the todo itself. It also allows us to not waste time explaining what we’re building…you already understand how it works.. we can focus on the real topic at hand.
One feedback and maybe I am nitpicking here, but all your tests were green before you started implementing anything. Next time maybe consider omitting the callback in you test, so it would be shown as skipped rather than passed. Why Jest shows them as green is another interesting question, maybe it changed since the recording of this video - I myself usually use mocha not jest.
I think that’s just how it is with jest, it assumes green unless it runs into an assertion that doesn’t pass, which I feel like makes sense. You can however explicitly mark a test with “test.todo()”to mark it as something you haven’t done
Love the video, but to me it's not TDD, you are having too many test unimplemented, and you are solving too many use cases at once
Yeah that’s fair.. but the point is in general that the tests are driving the direction of your implementation and isn’t written after the fact. The basic idea behind it is just write tests first, implement till tests pass, refactor, write more tests…continue/repeat the cycle…. Perhaps I didn’t do a good job of really showcasing that cycling because as you said, I perhaps wrote too many tests upfront. Will consider a follow up video to better explain that. Thanks for your input
I would suggest Don’t get hung up on things unimplemented though… this was quick video on the idea of TDD not necessarily a golden picture of what all should be tested for an API, that’s a topic on its own, but if you have feedback on what I should have tested, would be great if you elaborated on what those are
@@mariusespejo I just wanted to emphasize that if you have different test cases sometimes it seems that you do not focus on the case at the time. only that
@@mariusespejo I know that writing a test list is one of the techniques explained in the TDD book, and I see it great, it just mentioned that I would not implement them until I was able to solve thatI know that writing a test list is one of the techniques explained in the TDD book, and I see it great, it just mentioned that I would not implement them until I was able to solve the use case.
Thank you for the video I recommend you a JB Reinberger vídeo about integration test
wheres the code?