Test Driven Development: The best way to code that I almost never use

Test Driven Development is a fantastic way to build code that you know is well tested and will work. I know I should code this way, but why don't I? Let's find out what Test Driven Development is, and see if you should give it a try as we apply it to basic JavaScript and TypeScript functions, custom React hooks and React components.

👉 What's my theme? Night Wolf [black]
👉 What's that font? MonoLisa

00:00 Introduction
01:00 Project Setup
01:27 Test Setup
02:00 Our first TDD tests
06:27 Testing without Wallaby
06:55 TDD'ing React hooks
13:05 TDD'ing React components
17:48 Why I Don't TDD Often
19:00 Outroduction

Thank you for watching this video, click the "SUBSCRIBE" button to stay connected with this channel.

#tdd #react #reactHooks #testing

[dgrxd]

The production quality is just unbelievable.

[padonker]

In my network of indie developers I can't name one that uses TDD for client projects as these clients usually are fairly small companies. So telling these clients: "hey, it would be awesome to do this properly and add a X% overhead" is simply a non-starter and your competitor will run with the job. TDD is consistently presented as "you're doing it wrong unless you do this". But there are two factors that influence this decision that are rarely touched upon:
1. Working in teams or not. TDD becomes especially important when others work with your code but have no idea what it does. If you've built it all out yourself, the risks are just lower if you don't use TDD, IMHO.
2. Code lifetime. For most small company projects, the code is "refreshed" when a new developer is hired to do an overhaul of the existing system. I.e. the code just doesn't get a lot of changes before it's binned.

[tbcfrankee]

It makes sense to use TDD when the problem is well defined and you have requirements that are stable. But I can see how it would be a nightmare writing tests for something you don’t actually know if it’s possible yet. As a newbie I love TDD as it applies some degree of rigor to my code, but often learning to write the test is harder than writing the code itself, so I’m taking my time to learn it slowly.

[TokyoXtreme]

You've arguably got the best voice in the development community; I could listen all day 😂

[etorty_dev]

Great video 👍! I agree with your analogy with cooking where your ingredients are all prepared, clean and ready for you to cook.

For TDD, It implies that some thought or work has to be done beforehand to get the TDD workflow go smoothly.

Most tutors on YouTube start teaching from the "clean cooking table" so all the work of going to the garden or market to get the ingredients is not covered. The beginner doesn't have full context and therefore, can't start using TDD effectively in his work or see why this works.

The result is TDD is more "loved" than it is practised.

[hamzahmd_]

I just wonder to see how these tutorials are free on the internet. That's really genuine stuff. Awesome!

[listmaker]

Cooking videos is a cleverly done analogy. It summarizes all from the beginning

[passby]

My new favourite coding channel! So much treasure packed into each of your videos.

[JDLuke]

The title. It grabbed me by the lapels and shook me until my nose started bleeding.

[heyyrudyy]

I think test (incremental test) should be something that's work like git (incremental change). An agnotic system that will be based on the existing test Infrastructure per runtime and per language, where confidently, anyone can design, implement and push into the test execution tree which only run the added tests per module when it makes sense.

[shashikaxp]

Wow Jack, these videos keep getting better 😍

[bartek...]

I agree that snapshots are cancer and they are useless for TDD workflow. Any chance for more vid's with advance testing techniques? When to use mocking, when spying, when dependencies injection? and so on...

[krumbo]

Hey Jack there is a lot of confusion about testing in ReactJS. Can you please make some series on how to do that for Routers, for Hooks, for Context, for e2e, for a reducer state?

[ponderatulify]

I would also include this as a case by case basis. For example in some of the client work that I do, there is not much time for testing, EXCEPT when there is very complex business logic. There I need testing, because requirements keep coming in and I have to refactor the code.

So the situation transforms then from an ALL or NOTHING affair, to what is the most critical, complex part where testing is absolutely imperative.

[stevenstone]

I can't write back end code without doing TDD. It makes me feel unprofessional, like I'm leaving a job half done.

[mikkelhartung]

I’m curious to see how you would test components using react context.

[sawjunhao]

Great stuff for real world developers worry should do tdd or not. Keep it up. Thanks Jack

[thomasstambaugh]

I use "DDD" to mean "Debugger-Driven Development" -- it appears you're doing it already! I'm talking about working in an IDE like VisualStudio Code, so that most development happens while stuff is already running and -- for example -- paused at a breakpoint.

I'd really like to see more content like this. I tried to ramp up on "Enzyme" and gave up after trying to wrap tests around my first child of the top-level component.

I'm trying to wrap at least SOME tests around my front-end, because I want to be able to make changes to my front end with some confidence that I'm not breaking my world.

One key point that I think is worth emphasizing: happy-case behavior is, in my several decades of professional software development, is the easiest 10-20% of the total effort needed for a production-quality application. Sad-case behavior is MUCH harder, and I don't know how to do that without a test framework. I think that gets us to about 80-90% of the effort. It's been my experience that that last 10-20% can't be done prior to deployment (sadly).

The most expensive -- economically and in terms of career impact on the developers -- failures are, in my experience, obvious errors in code that is difficult to test, rarely run, and extraordinarily expensive when it fails. I'm talking about things like an exception handler in an interpreted language that isn't even compiled -- never mind executed -- until some catastrophe ("DISK CONTROLLER FAILURE") occurs. Such code can have obvious syntax errors, even in production, because it can be very difficult to inject the exception condition into the code during testing. The result is an exception handler is never called and therefore never compiled.


Kudos and props for doing this, and I look forward to more like it.

[Mostafaabobakr]

Thank you Jack,
What is the extension that autocomplete code before you write it ?

[juanpasten]

So interesting. Thanks for create and share