No video
NodeJS Express Test-Driven API Development (TDD)
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.
Пікірлер: 66
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!
@___GM___
3 жыл бұрын
Hi. What do you think of prisma vs typeorm ? Which is best suited for nestjs?
@mariusespejo
3 жыл бұрын
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.
I do not know why this video has less then 100K views . Really amazing Content and TDD really well explained . Thanks .
Brilliant! Very useful. Got me started on TDD
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
@mariusespejo
2 жыл бұрын
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 Marius i got a lot better understanding of TDD thanks to your video....
Great video, thanks! BTW Marius is a strong name.
This has been explained beautifully.
Fast and crystal clear. Thank you.
Awesome! I like your way of explaining, clean and clear, cannot wait for another great content ❤️
@mariusespejo
3 жыл бұрын
Happy to hear that! thank you!
Excellent Marius, this video helped me a lot in recognition TDD idea and how to use it in nodejs environment ♥
Very clear tutorial
@mariusespejo
2 жыл бұрын
Thanks!
Very well explained. Thanks for the video.
Thanks for sharing such a good content. It helped me a lot.
Thanks! Hoping to see more fundamentals videos. Maybe something on load time and request calls
@mariusespejo
3 жыл бұрын
will take note of those, thanks!
Thanks, this is very clear and helpful!
Thank you so much for this video.
thanks for sharing this video. clearly explained.
Galing sir! nahanap ko din to
nice bro !!! thanx .. please more content node express and Redux
@mariusespejo
3 жыл бұрын
Sure thing!
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
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.
11 out of 10 for testing video
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?
excellent video!
Hi Marius, excellent video. Do you have the repository for the code somewhere to access?
@mariusespejo
2 жыл бұрын
Ah sorry not at the moment
thank you so much this was awesome!
@mariusespejo
Жыл бұрын
you’re welcome!
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?
@mariusespejo
2 жыл бұрын
Yeah pretty much either mock it or use an in-memory one just for tests however that adds a bit of overhead to setup
@snake1625b
2 жыл бұрын
@@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?
@mariusespejo
2 жыл бұрын
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.
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?
@mariusespejo
Жыл бұрын
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 you !
Thanks helped a lot ! Just curious what extensions do you use in vs code?
@mariusespejo
3 жыл бұрын
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?
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 ??
@mariusespejo
Жыл бұрын
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
Thank you so much
@mariusespejo
3 жыл бұрын
you’re welcome!
Cool. But in real-world application we have DB and API calls. How we should deal with them in tests?
@mariusespejo
2 жыл бұрын
you can either mock those calls or have a real in memory database that you make queries to
Hey Which Code formatter are you using ?
@mariusespejo
2 жыл бұрын
I use and suggest prettier for pretty much any JS project
how to get that '-->' same as yours ?? it is different in mine
@mariusespejo
3 жыл бұрын
not sure what you mean, like in the test message? it’s literally just dash dash chevron, nothing fancy
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.
@mariusespejo
3 ай бұрын
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
When I see or hear "lets build a todo.... " I close the tab
@mariusespejo
Жыл бұрын
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.
wheres the code?
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
@mariusespejo
3 жыл бұрын
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
@mariusespejo
3 жыл бұрын
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
@emmanuelvalverderamos
3 жыл бұрын
@@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
@emmanuelvalverderamos
3 жыл бұрын
@@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