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.
I agree, I'm kinda positioning this as TDD is the "ideal" but in my practical experience it's rarely used because of exactly the issues you are talking about.
@@jherr Yes, and I thank you for it! I feel like it is seen as a sin if you admit you're not using TDD on some project. We need to stop the TDD-Shaming :-)
@@padonker I have experienced the same in the past. It comes up as a hot topic when planning new projects, but most developers don't want to drive the implementation since the extra amount of work in a larger project don't seem to satisfy their visual output time. So unless you have a small team working on a project together and each understanding how to implement TDD properly, you might just have TDD as "tech debt", prioritized below the bugs, ironically.
@@padonker Would it not be easier to implement TDD starting small, for example, within a Microfrontend architecture where individual teams can focus on their features or components to be written using TDD? Developers likes small wins, and the way that Jack has suggested on how to start the implementation is small enough to make possible big wins. Start small, go Big :)
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.
@@veedjohnson I just UA-cam searched "testing for --whatever framework--". For example I searched "vitest mock api" if I wanted to figure out how to mock an API for Vitest.
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 UA-cam 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.
I agree. I almost never use TDD, but I'm super excited when the team comes up with a project that is super well bounded and understood, and it's just a question of execution, and the engineers look at each other and say "Finally, we can use TDD!" :) Because at the end of the day that TDD'ed code is awesome. But projects are rarely ever that well defined.
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.
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...
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?
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.
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.
I agree with your choices about when to do TDD, but boy is it frustrating to encounter a code base in which you must write tests that was not written with testing in mind.
The initial example is incorrect. You want the first run to fail (not to a compilation error, but due to invalid code) and then write enough code to make it pass. Then refactor. This way you get the correct feedback.
Great content, but I just wanted to throw my 2 cents in here regarding your final comments around not testing enough in real projects. I'd strongly recommend that when you work on PoC you "throw the code away", repeat with me "throw the code away" and instead focus on test drive the production code with the learnings from your PoC (you don't have to literally throw it away, you can still use it as a reference).
Next video, why blue and purple show as difference color on browser, app etc. How we fix that with code, so we and user can see the same color. I found this on chrome and firefox on blue and purple color. Blue to purple and purple to blue
Use testing as a design tool or specification. What you did is mostly unit test. A good portion of TDD advocates are of the opinion that you should delete unit tests. Lest's say you have to implement user creation. - if you are at this point you probably have a design lined up for you. That design has buttons, inputs, etc. If you follow the design,.. you need to open up the page, press the "Create user" button, input field1, input field2, press the "Create" button. All of this process can be rendered into executable code. - If you are doing end to end, an API call should fire with field1and field2. - If you are doing acceptance, after the user list refresh you should be able to search and find the user that you just created. Test what really matters to your clients. I've not seen a single client that is interested in the correct clamping function but i've seen many who expect newly created things to.. well.. exist. Now it is arguable that a library with a clamp function should have a working clamping function since your clients are developers who are effectively using that function, but you should get my point.
That's the philosophy of Test Driven Development. The tests drive the development. I don't use it all the time, but for some projects, particular business logic libraries, it's a good idea.
Great Jack, just a quick question, what is the extension name you used for code suggestion, I think you said github cli suggestion here ua-cam.com/video/EH9Suo_J4Ks/v-deo.html. I didn't find it
![[UA] Eternal Fire проти NAVI | EPL Season 20 Malta](http://i.ytimg.com/vi/chvlsDygrZM/mqdefault.jpg)
The production quality is just unbelievable.
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.
I agree, I'm kinda positioning this as TDD is the "ideal" but in my practical experience it's rarely used because of exactly the issues you are talking about.
@@jherr Yes, and I thank you for it! I feel like it is seen as a sin if you admit you're not using TDD on some project. We need to stop the TDD-Shaming :-)
i watch and confuse.. don't use tdd either for business process .. data flow diagram instead.
@@padonker I have experienced the same in the past. It comes up as a hot topic when planning new projects, but most developers don't want to drive the implementation since the extra amount of work in a larger project don't seem to satisfy their visual output time. So unless you have a small team working on a project together and each understanding how to implement TDD properly, you might just have TDD as "tech debt", prioritized below the bugs, ironically.
@@padonker Would it not be easier to implement TDD starting small, for example, within a Microfrontend architecture where individual teams can focus on their features or components to be written using TDD? Developers likes small wins, and the way that Jack has suggested on how to start the implementation is small enough to make possible big wins. Start small, go Big :)
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.
Hi mate, please can you share resources you’re using to learn to write tests?
@@veedjohnson I just UA-cam searched "testing for --whatever framework--". For example I searched "vitest mock api" if I wanted to figure out how to mock an API for Vitest.
You've arguably got the best voice in the development community; I could listen all day 😂
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 UA-cam 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.
I agree. I almost never use TDD, but I'm super excited when the team comes up with a project that is super well bounded and understood, and it's just a question of execution, and the engineers look at each other and say "Finally, we can use TDD!" :) Because at the end of the day that TDD'ed code is awesome. But projects are rarely ever that well defined.
@@jherr Spot on, Boss :)
Cooking videos is a cleverly done analogy. It summarizes all from the beginning
Indeed. It appears that Jack is a cook -- another huge plus.
I just wonder to see how these tutorials are free on the internet. That's really genuine stuff. Awesome!
My new favourite coding channel! So much treasure packed into each of your videos.
The title. It grabbed me by the lapels and shook me until my nose started bleeding.
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.
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...
+1 for more testing videos.
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?
Wow Jack, these videos keep getting better 😍
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.
So interesting. Thanks for create and share
Great stuff for real world developers worry should do tdd or not. Keep it up. Thanks Jack
Awesome Jack, Thanks alot
nice to see your kitchen
I can't write back end code without doing TDD. It makes me feel unprofessional, like I'm leaving a job half done.
Well, if you don't write tests, then the job is half done. :) It's just a question of writing them before or after you write the implementations.
Would be cool if you did a video covering Feature Driven Development.
Such a cool teacher dude!
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.
I agree with your choices about when to do TDD, but boy is it frustrating to encounter a code base in which you must write tests that was not written with testing in mind.
I thought we were going to cook today
A video on Error Driven Development would be good.
WOW. It would be quite interesting if you start with "Hello everyone. Welcome to my kitchen.". 🤣
The initial example is incorrect. You want the first run to fail (not to a compilation error, but due to invalid code) and then write enough code to make it pass. Then refactor. This way you get the correct feedback.
Thank you Jack,
What is the extension that autocomplete code before you write it ?
GitHub Copilot
Next topic Domain Driven Design DDD please !
Great content, but I just wanted to throw my 2 cents in here regarding your final comments around not testing enough in real projects. I'd strongly recommend that when you work on PoC you "throw the code away", repeat with me "throw the code away" and instead focus on test drive the production code with the learnings from your PoC (you don't have to literally throw it away, you can still use it as a reference).
Great stuff! What extension is putting the Debug / View Story links over each test?
Wallaby. Link in the description.
Jack I still can't find the link to buy the futuristic car. Cash in hand.
Would it be self-driving to? I'm probably not a great pilot.
@jack is that really a garden behind you or its a painting only ??
It's real.
@@jherr its amazing 🤩
I’m curious to see how you would test components using react context.
I just create a mock context and wrap the component in that. Seems to work for me. It's actually a nice way to pull of dependency injection.
How do you know correct `role` to choose from? There are so many of them
thank you for this video Jack, do you know someone or any resources I could look into in how to test a Vue Js application?
Not off hand. Sorry. I'm sure there are though!
Next video, why blue and purple show as difference color on browser, app etc. How we fix that with code, so we and user can see the same color. I found this on chrome and firefox on blue and purple color. Blue to purple and purple to blue
next video: react testing sir
Teacher!
When will the baking tutorial be out??
You have to go deep in the memory banks for that one: ua-cam.com/video/P2n3huc2gO4/v-deo.html
@@jherr Your channel really does have it all!
@@kieranharte I've also got a woodworking video (actually two I think) if you want those.
@@jherr well that's a coincidence - coding, baking, and woodwork (woodturning) are my three hobbies!!
Use testing as a design tool or specification. What you did is mostly unit test. A good portion of TDD advocates are of the opinion that you should delete unit tests.
Lest's say you have to implement user creation.
- if you are at this point you probably have a design lined up for you. That design has buttons, inputs, etc.
If you follow the design,.. you need to open up the page, press the "Create user" button, input field1, input field2, press the "Create" button. All of this process can be rendered into executable code.
- If you are doing end to end, an API call should fire with field1and field2.
- If you are doing acceptance, after the user list refresh you should be able to search and find the user that you just created.
Test what really matters to your clients. I've not seen a single client that is interested in the correct clamping function but i've seen many who expect newly created things to.. well.. exist.
Now it is arguable that a library with a clamp function should have a working clamping function since your clients are developers who are effectively using that function, but you should get my point.
thanks for sharing, it's posible to create a tutorial for node js api testing ?
What in particular are you looking 'fer?
@@jherr testing CRUD with tdd
@@TheSldsnake Hmmmm... Maybe like a testing NestJS type deal?
Do we need to write a test first before actually coding/implementing the code?
That's the philosophy of Test Driven Development. The tests drive the development. I don't use it all the time, but for some projects, particular business logic libraries, it's a good idea.
Great Jack, just a quick question, what is the extension name you used for code suggestion, I think you said github cli suggestion here ua-cam.com/video/EH9Suo_J4Ks/v-deo.html. I didn't find it
GitHub Copilot.
@@jherr ❤️ thanks
TDD sounds great in theory. Even better than communism.
Thanks a lot for sharing ! please unzoom your code
using `act` is a smell. Gotta get better bro, and not misinform people as people will start copying you and start testing hooks
Ok, so it would help folks who look at the comments here to understand WHY you think act is a code smell.
Testing a hook is testing implementation details. You gotta get better bro
Besy way is to do, TDD with DDD on real project. And React kids, don't know what is DDD. So why TDD?