9 ms·

I think the types of testing that are useful are critically dependent on the language we're talking about. If you're working with a dynamic language like Ruby,

by ufmace 6y ago

I think the types of testing that are useful are critically dependent on the language we're talking about. If you're working with a dynamic language like Ruby, Python, Javascript, then it's more valuable to have micro-tests on every little thing, because there's no compile step to find typos or type conversion errors. If you're working with something more static, like C#, Java, Go, Rust, etc, then it usually doesn't make sense to write tests like that. Better to stick to higher-level tests that ensure your classes are working together correctly. Except for the case of particularly tricky algorithms of course. I also say, don't be scared of hundreds of tests breaking. Very likely there is only one actual bug. Pick one failing test, run that one alone, fix whatever is broken, and then run the suite again. Usually you'll have fixed most of them.

ravenstine 6y ago
They're also dependent on what it is that you're building. If you're writing an application, the value of unit tests is limited because the APIs internal to the application aren't being consumed by another developer but instead a user who's going to click/tap through an interface. So, in that case, it makes more sense to test the behavior expected to result from user interaction rather than test the return values of a given function, for instance, because it doesn't matter if a function does the right thing when the app is rendering a blank screen. You can test way more functionality at once by testing at the integration level or by writing "application" tests. Unit tests are best suited for two situations; either you've got a function where it's simply faster/easier to make sure it does the right thing by using a unit test, or you're writing an API that other developers will be consuming in their own applications.
rectang 6y ago
> If you're working with something more static, like C#, Java, Go, Rust, etc, then it usually doesn't make sense to write tests like that. I wouldn't trust myself to write code without unit testing it, nor would I trust you, nor would I trust anybody else. It is all too easy to make mistakes like off-by-one errors or other edge case misbehavior.
- TillE 6y ago
  I've seen the opinion "static typing obviates the need for unit tests" expressed pretty frequently, and I can merely gape utter bafflement. I like static typing, but it's not magic pixie dust. Start with the fact that unit testing was widely popularized with Java.
  - closeparen 6y ago
    You have literally no idea whether an untested line in a dynamic language could ever work. A line in Java that compiles but doesn't have test coverage still probably does what it says, and how badly you need that test coverage depends on the complexity of what it says.
- quicklime 6y ago
  I'm not the person you're replying to, but I don't think that's what they're saying. When I write Python, I'm paranoid that someone will pass a string instead of an int to my function. Or that when I for-loop over my tuple of strings, I'll accidentally iterate over the characters in the (single) string of my (1-)tuple, instead of the many strings in a n-tuple (with n>1). So I write unit tests to cover these specific cases. When I'm writing Java or Go, I write all the other tests, but not those ones. Because the type checker would catch those problems for me.
- ufmace 6y ago
  I'm not saying to not write any micro-tests at all, just that most of them are not needed - use your judgement of course. Don't bother writing tests for things that your type system and compiler already protect you from. I do find that off-by-one errors are much harder to make, in both static and dynamic languages, when you use the collection looping and manipulation constructs that almost every language has now, instead of C-style triple-statement for loops.

by ufmace 6y ago

ravenstine 6y ago

They're also dependent on what it is that you're building. If you're writing an application, the value of unit tests is limited because the APIs internal to the application aren't being consumed by another developer but instead a user who's going to click/tap through an interface. So, in that case, it makes more sense to test the behavior expected to result from user interaction rather than test the return values of a given function, for instance, because it doesn't matter if a function does the right thing when the app is rendering a blank screen. You can test way more functionality at once by testing at the integration level or by writing "application" tests. Unit tests are best suited for two situations; either you've got a function where it's simply faster/easier to make sure it does the right thing by using a unit test, or you're writing an API that other developers will be consuming in their own applications.

rectang 6y ago

> If you're working with something more static, like C#, Java, Go, Rust, etc, then it usually doesn't make sense to write tests like that. I wouldn't trust myself to write code without unit testing it, nor would I trust you, nor would I trust anybody else. It is all too easy to make mistakes like off-by-one errors or other edge case misbehavior.

TillE 6y ago
I've seen the opinion "static typing obviates the need for unit tests" expressed pretty frequently, and I can merely gape utter bafflement. I like static typing, but it's not magic pixie dust. Start with the fact that unit testing was widely popularized with Java.
- closeparen 6y ago
  You have literally no idea whether an untested line in a dynamic language could ever work. A line in Java that compiles but doesn't have test coverage still probably does what it says, and how badly you need that test coverage depends on the complexity of what it says.
quicklime 6y ago
I'm not the person you're replying to, but I don't think that's what they're saying. When I write Python, I'm paranoid that someone will pass a string instead of an int to my function. Or that when I for-loop over my tuple of strings, I'll accidentally iterate over the characters in the (single) string of my (1-)tuple, instead of the many strings in a n-tuple (with n>1). So I write unit tests to cover these specific cases. When I'm writing Java or Go, I write all the other tests, but not those ones. Because the type checker would catch those problems for me.
ufmace 6y ago
I'm not saying to not write any micro-tests at all, just that most of them are not needed - use your judgement of course. Don't bother writing tests for things that your type system and compiler already protect you from. I do find that off-by-one errors are much harder to make, in both static and dynamic languages, when you use the collection looping and manipulation constructs that almost every language has now, instead of C-style triple-statement for loops.