2 min

Tests the tests by making them fail 3 Minutes with Kent

    • Technology

https://kentcdodds.com/blog/make-your-test-fail
Hello there friends. I'm just driving now. I was thinking about a blog post
that I wrote a while ago. I think it was called break your tests or
something like that, but the idea is that it's just really easy to write a
test that passes and so you feel really good about it this this especially
happens if you're testing after you've already implemented something if
you're doing TDD this is maybe less of a problem, but it's really easy to
write a test that's green and we're happy with it and,So we commit it and
we move on and then we later find out that that test wasn't running to
completion or it was the it wasn't testing what we thought it was testing
wasn't making the right assertions or something and so it wasn't actually
doing what we thought it was and so then the thing that we were intending
to test ends up breaking in that test doesn't doesn't save us from that and
so what I suggest that you do is you take the time to actually try and make
the thing that you're testing break, so you simulate a failure this could
be.
I'm pretty much like any any step of the process of what it is that you're
testing maybe you're making a request to get some data and then you're
displaying that data in your asserting that the data is displayed properly
and so you could just comment out the code that updates the state or
something like that and so it's normally very easy and it's a manual check.
I don't think that there would be a whole lot of use in like at this point
you're testing the tests and I don't see a whole lot of benefit and like
how far do you go, do you test the test the test the test?It's just sorry
cracking myself up um yeah so like at some point you have to say okay,
we're good with just doing a manual verification of this and so that's
that's what this is is just a manual verification that yes this is indeed
testing what I think it is and I verified that by commenting out the
implementation or changing the implementation and in a certain way to make
sure that the test will catch me if I mistakenly change the implementation
in this way, so yeah, as you're writing your test for your software, I
suggest that you break the test and I will.
Add a link to the blog post where I dive into this little in a little bit
more detail at the top of the notes for this episode so you can go take a
look at that. I hope you have a wonderful day and we will chat with you
later bye.

https://kentcdodds.com/blog/make-your-test-fail
Hello there friends. I'm just driving now. I was thinking about a blog post
that I wrote a while ago. I think it was called break your tests or
something like that, but the idea is that it's just really easy to write a
test that passes and so you feel really good about it this this especially
happens if you're testing after you've already implemented something if
you're doing TDD this is maybe less of a problem, but it's really easy to
write a test that's green and we're happy with it and,So we commit it and
we move on and then we later find out that that test wasn't running to
completion or it was the it wasn't testing what we thought it was testing
wasn't making the right assertions or something and so it wasn't actually
doing what we thought it was and so then the thing that we were intending
to test ends up breaking in that test doesn't doesn't save us from that and
so what I suggest that you do is you take the time to actually try and make
the thing that you're testing break, so you simulate a failure this could
be.
I'm pretty much like any any step of the process of what it is that you're
testing maybe you're making a request to get some data and then you're
displaying that data in your asserting that the data is displayed properly
and so you could just comment out the code that updates the state or
something like that and so it's normally very easy and it's a manual check.
I don't think that there would be a whole lot of use in like at this point
you're testing the tests and I don't see a whole lot of benefit and like
how far do you go, do you test the test the test the test?It's just sorry
cracking myself up um yeah so like at some point you have to say okay,
we're good with just doing a manual verification of this and so that's
that's what this is is just a manual verification that yes this is indeed
testing what I think it is and I verified that by commenting out the
implementation or changing the implementation and in a certain way to make
sure that the test will catch me if I mistakenly change the implementation
in this way, so yeah, as you're writing your test for your software, I
suggest that you break the test and I will.
Add a link to the blog post where I dive into this little in a little bit
more detail at the top of the notes for this episode so you can go take a
look at that. I hope you have a wonderful day and we will chat with you
later bye.

2 min

Top Podcasts In Technology

Acquired
Ben Gilbert and David Rosenthal
All-In with Chamath, Jason, Sacks & Friedberg
All-In Podcast, LLC
Lex Fridman Podcast
Lex Fridman
Hard Fork
The New York Times
TED Radio Hour
NPR
Darknet Diaries
Jack Rhysider