Introduction to Test Driven Development with React

In this video we learn how to apply Test Driven Development(TDD) to a react application. TDD is a test first approach. That means you write a failing test first. After the test is written you write the code to make it pass.
We will create an application using TDD and the amazing part is that we will only run the application at the end of the video. We will rely on our unit tests to build a working application!
The testing library that will use is called Testing Library(testing-library.com/). When you use npx create react app it comes preloaded.
GitHub
github.com/CodingWith-Adam/td...

[@moraisgabas]

Awesome content here. Finally, a case for understanding the utility and power of TDD in clear way. Thanks, Adam.

[@CodingWithAdam]

You’re welcome! I’m really glad the tutorial helped! 😀

[@joumanax]

Great tutorial! I just recently found out about TDD but haven't looked into it until you posted this. Thank you for this intro! :)

[@CodingWithAdam]

Thank You Joumana! You're welcome. Once you get into the flow TDD it can be a lot of fun. Glad you enjoyed the tutorial.

[@mj2068]

for someone like me that haven't thought much about tests before, it just blew my mind when the first thing you did after project creation is to run the test command.

[@CodingWithAdam]

Thank you! It creates sense of confidence knowing that all the tests are passing. Specially when you work on a large team 😁

[@keifer7813]

This was great. I'd love to see more of this. Maybe a slightly more complex set of react tests to mimic a professional working environment

[@CodingWithAdam]

Thank you!! That's a great suggestion!

[@HarshSingh-ll1sq]

god bless you man never got so much clearity

[@CodingWithAdam]

You’re welcome! I’m really glad that video was helpful to understand TDD with react! 😁

[@midclock]

This is an awesome explanation! Other than TDD applied to a real world example, it made me understand a little more about how React works (I used to work with Vue.js before)

[@CodingWithAdam]

Thank you! I’m really glad the video was helpful in understanding TDD and react! 😀

[@_k-nd]

This was so very helpful, thank you!

[@CodingWithAdam]

You’re welcome! Glad the video was helpful!

[@lezboy5385]

Really nice tutorial, helped me a lot! Keep up the nice content, you earned a sub :)

[@CodingWithAdam]

Thank you. I’m really happy the tutorial helped! Thank you for the sub!!!

[@sabarnabasak1677]

Great explaination man ! Thanks

[@CodingWithAdam]

Thank you! I’m glad the video helped.

[@OtisDeLarge]

I found this very helpful. Thank you.

[@CodingWithAdam]

You’re welcome! Happy the video was helpful!

[@LunaSmithArt]

A lovely introduction to TDD with React. Nicely done and simple to follow. Can you make a video with TDD/React and Typescript? Happy Halloween 🍭🎃🍬🐈‍⬛

[@CodingWithAdam]

Thank you Luna! I’m happy that enjoyed the tutorial! That’s a wonderful suggestion, I will add it to my list of future videos. Happy Halloween 🎃🐈‍⬛

[@MohamedAfzalMullaTweetzal]

Great video Adam! 💯

[@CodingWithAdam]

Thank you! Glad you liked the video. 😁

[@manishamuskan6755]

Awesome video... One request though - Please make a video where we can test advanced features like mocking a server request, routing etc with the same TDD approach...

[@CodingWithAdam]

Thank you for the great suggestion! I’ll consider it for a future video.

[@aryanrahman3212]

Great intro!

[@CodingWithAdam]

Thank you! Glad you enjoyed it!

[@theagiletester6285]

Very nice Adam.

[@CodingWithAdam]

Thank you! 😀

[@stamatispsarras]

I am not familiar with React but this video made me understand it better, since you were building it in small steps. TDD FTW. BTW I do not understand why you had to test if you clicked twice? You never proved that this test was failing (other than when it was simply throwing an exception). In my understanding of TDD, you need to write a test completely, prove that it fails. You did that in most scenarios, but not on the ones you were checking for multiple clicks.

[@CodingWithAdam]

Agree TDD and testing in general are great and help to build confidence when changing code to ensure nothing has broken. Great question. As with any best practice like agile or TDD you can pick and chose how to use it. Testing can be about coverage and seeing if you can break anything. Clicking a button fast twice could yield an incorrect result in this situation it was an extra coverage test. We could have written the first test so that clicking the button once would hard code the value to 1. This would cause the click button twice test to fail. This can be a fun exercise to write just the code needed to make a test pass. This can be done with pair programming where one writes the test and the other makes it pass The important thing is that there is a test. As you observed with strict TDD you write the test first see the failure and make it pass. Hope this helps!

[@mgcmsn]

Thank you sir!

[@CodingWithAdam]

You’re welcome!

[@matthewrideout426]

Thanks :)

[@CodingWithAdam]

You’re welcome!

[@Ricardoromero4444]

I mean, this shows the workflow of TDD very well... but that's kind of obvious. When you get a feature request, how do you decide what tests to write? How do you write good tests? How do you avoid writing a bunch of useless tests?

[@CodingWithAdam]

Thanks for the question. An easy way is to use a coverage report to determine if you are executing all branches of your code ex if else etc. Also ask your self the question do my tests provide confidence that my application is working correctly? Will it prevent other devs from making mistakes. Those are a few of the things I think about.

[@mks-h]

@@CodingWithAdam "if you are executing all branches of your code" and now the test is heavily tied to the code, which in TDD shouldn't even exist until after you write a test. Instead, I'd say you have to test all ways the component is supposed to be used (or all states it supposed to be in, and transitions between them).

[@Razkazar]

!

[@CodingWithAdam]

Thank you!!! 😁

[@desajustecreativo]

Writing the list of tests ahead of time breaks the second rule of TDD: “You are not allowed to write any more of a unit test than is sufficient to fail”

[@CodingWithAdam]

That’s right the 3 laws of TDD from Robert C Martin (Uncle Bob). Really helps to achieve a very high test coverage percentage 😁 butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

[@Nekenbeker]

@@CodingWithAdam The point of doing minimal amounts of work in every step is not having great test coverage, this is merely a side product. The main point is to minimize cognitive load. If you do 10 failing tests in advance you not only have to think of the functionality you are currently implementing but also how many tests have failed before and what should my test-suite green-rate be right now. In formal TDD the whole test suite has to be green after the implementation step no matter what.

[@lucasa8710]

tnx a lot

[@CodingWithAdam]

You’re welcome!

[@ElderESG]

What happens if you have more of the same text on the screen. Maybe make a tutorial on a more complex project. Thanks!!!

[@CodingWithAdam]

Great question. In that situation I would suggest using a testId. Here is the documentation testing-library.com/docs/queries/bytestid Thank you for the suggestion of making a more advanced example.

[@killian_mcmillan]

@@CodingWithAdam I was thinking the same thing (about using queryByText). I actually paused the video and tried to do it myself. As you said, *testId* would be the way to go (in lot of cases here), but I get it that this is more of an introduction video than building a production app. Also, I think it's better to provide the default value in the component's props, e.g.: const AwesomeCounter = ({ initialValue = 0 }) => { ...... As your component grows, it's easier to keep track of default values. Also, for preventing negative values, I would say it's nicer to write something like: const remove = () => { setCounter((prev) => prev > 0 ? prev - 1 : 0) } Just my 2 cents :) Thanks for this great video! Keep it up! I learned something new today and that's what's priceless! Cheers!

[@CodingWithAdam]

Thank you Killian! I’m glad you learned something new and thank you for the suggestions!

[@Jrrs2007]

Nice.

[@CodingWithAdam]

You’re welcome!

[@damindadineshimaduwagamage9044]

in TDD, how do we know if the tests are correct?

[@CodingWithAdam]

That is a great question. One way is to use a coverage report to see if your test code is executing all paths of your code.

[@Nekenbeker]

Well the implementation tests your test. The TDD cycle is: Write a test and it must fail. Then write minimal and simplest code possible to make the test green. At this time you should know that your test is testing for your intention as it fails when the code does not what it's supposed to do but is green when the code does work. After that you refactor, i.e. make the code less stupid keeping the tested test green.

[@MovaClub]

many thanks!

[@CodingWithAdam]

You’re welcome!