Sign up to save your podcasts
Or
Share TypeScript is testing
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
TypeScript is testing
https://kcd.im/trophy
https://kentcdodds.com/blog/eliminate-an-entire-category-of-bugs-with-a-few-simple-tools
TypeScript is tests. Tests are type script. So type script is just a way to
give yourself more confidence. Sure, it helps you in your workflow, it
makes you a faster as you're developing because you have autocomplete and
stuff like that. And testing does the same thing as well as you
refactoring, you know that you didn't break anything you get a much faster
feedback when you you're running your tests as you're working on things.
And both of these also make the initial code take longer. So it takes more
time to think.About the types that you're writing takes more time to
actually write the tests. And they can also be an enormous time sink where
you spend a ton of time working on a task or a ton of time working on the
on the types and then you've later realized that you don't need that code
at all so you just throw all that work away.
So, I I find that typescript and testing are way more related than they are
or similar than they are different. And I think this is a good thing
though, the whole goal is to be more confident in the changes that
were.Making in the application that were shipping. And the cool thing about
TypeScript is that it eliminates an entire category of bugs.
I actually have a blog post about that. And it also eliminates an entire
category of tests, which you're probably not writing but maybe you should.
So one of the things about code coverage is that it doesn't what we really
actually need is data coverage or use case coverage because you may have a
function called ad that accepts two numbers and add.
S them together and you could write a couple of tests for that if you
wanted to but you're probably not writing like it's not very normal for
people to write a test that says what happens if I pass a string what
happens if I pass a boolean but you know, what a you might have a test that
says what happens if I don't pass the arguments or something and because
there are some defaults.
But and that and because there are defaults you're going to want to cover
that. But we've very often don't do a whole lot of defensive programming
and runtime and type assertions of.You know, what the arguments that were
passed? Maybe you do that for some of your functions, but probably not all.
And so you can you don't get a much confidence in in that aspect. And you
you could but it's just way easier to just use a type to language like
TypeScript and then that entire category of bugs in the entire category of
tests don't need to be written. So type script is tests.
View all episodes
By Kent C. Dodds
5
44 ratings
https://kcd.im/trophy
https://kentcdodds.com/blog/eliminate-an-entire-category-of-bugs-with-a-few-simple-tools
TypeScript is tests. Tests are type script. So type script is just a way to
give yourself more confidence. Sure, it helps you in your workflow, it
makes you a faster as you're developing because you have autocomplete and
stuff like that. And testing does the same thing as well as you
refactoring, you know that you didn't break anything you get a much faster
feedback when you you're running your tests as you're working on things.
And both of these also make the initial code take longer. So it takes more
time to think.About the types that you're writing takes more time to
actually write the tests. And they can also be an enormous time sink where
you spend a ton of time working on a task or a ton of time working on the
on the types and then you've later realized that you don't need that code
at all so you just throw all that work away.
So, I I find that typescript and testing are way more related than they are
or similar than they are different. And I think this is a good thing
though, the whole goal is to be more confident in the changes that
were.Making in the application that were shipping. And the cool thing about
TypeScript is that it eliminates an entire category of bugs.
I actually have a blog post about that. And it also eliminates an entire
category of tests, which you're probably not writing but maybe you should.
So one of the things about code coverage is that it doesn't what we really
actually need is data coverage or use case coverage because you may have a
function called ad that accepts two numbers and add.
S them together and you could write a couple of tests for that if you
wanted to but you're probably not writing like it's not very normal for
people to write a test that says what happens if I pass a string what
happens if I pass a boolean but you know, what a you might have a test that
says what happens if I don't pass the arguments or something and because
there are some defaults.
But and that and because there are defaults you're going to want to cover
that. But we've very often don't do a whole lot of defensive programming
and runtime and type assertions of.You know, what the arguments that were
passed? Maybe you do that for some of your functions, but probably not all.
And so you can you don't get a much confidence in in that aspect. And you
you could but it's just way easier to just use a type to language like
TypeScript and then that entire category of bugs in the entire category of
tests don't need to be written. So type script is tests.