tag:blogger.com,1999:blog-8648268364549955959.post5190524931388429558..comments2024-03-28T11:52:10.996+00:00Comments on the literate programmer: Types don't substitute for testsctfordhttp://www.blogger.com/profile/05464902188219000642noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-8648268364549955959.post-76557263150248497412014-10-23T15:33:02.695+01:002014-10-23T15:33:02.695+01:00Good point, Chris. I was specifically thinking of ...Good point, Chris. I was specifically thinking of unit tests.<br /><br />I've had feedback from yourself and others about the value of integration/component tests that check contracts from a high-level, and that these are proving properties of data that are type-related.<br /><br />A large number of these integration tests can be a sign of too few unit tests or code that's hard to reason about, but that's another argument.ctfordhttps://www.blogger.com/profile/05464902188219000642noreply@blogger.comtag:blogger.com,1999:blog-8648268364549955959.post-8713620852051937952014-10-23T15:15:47.310+01:002014-10-23T15:15:47.310+01:00In my experience, writing in an untyped language m...In my experience, writing in an untyped language means doing without the kind of guarantees a type system provides. Having strong testing in other ways makes up for that to some extent, but I don't think that users of untyped languages replace type safety.<br /><br />Having said that, property-based testing looks like a really interesting way to prove things about a system, even things that are hard to express in a type system.ctfordhttps://www.blogger.com/profile/05464902188219000642noreply@blogger.comtag:blogger.com,1999:blog-8648268364549955959.post-7627826043016536292014-10-20T20:45:19.550+01:002014-10-20T20:45:19.550+01:00When you're working in an untyped language, yo...When you're working in an untyped language, you write all the unit tests you would write in a typed language, sure, and establish the same properties. But what about the additional properties that you would have established via the type system? How do you establish those properties in the untyped language? Either those properties are not valuable to establish, not something you make mistakes about - in which case typing is useless. Or they are valuable, which means you do need to establish them in the untyped languages. In which case, what other method can you use to do so except by writing more unit tests that you wouldn't have written in the typed language?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8648268364549955959.post-49097346691057708032014-10-20T16:08:18.647+01:002014-10-20T16:08:18.647+01:00Hear, hear.Hear, hear.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8648268364549955959.post-79562351283005754112014-10-20T15:08:40.096+01:002014-10-20T15:08:40.096+01:00I take it you're using "unit tests" ...I take it you're using "unit tests" in the original narrow sense of a test that exercises a single unit of functionality in isolation? I'm not sure if you're right in this post, but it seems to me that your argument is strongest when it comes to this kind of test.<br /><br />Or, to put it another way: It seems to me that your argument gets weaker as we consider tests more broadly. <br /><br />I don't know about you, but *I* need to write *some* functional and integration tests in dynamic languages that are *not* needed in a language with a sensible type system. This is because I make all kinds of brain-dead stupid errors when my components start interacting even when all the components are working well in isolation (as confirmed by unit tests). I pass an int where a string was required, etc. Stuff breaks at the boundaries of components, in their interactions. When I go to work and write Python, I just have to test for goofy stuff like that (along multiple code paths). When I come home and play around with Haskell, I just don't: I line up a bunch of functions and the compiler tells me right away that I did something stupid.<br /><br />Anyway, it seems to me that there *are* a class of tests that a good type system saves us from writing, and that these tests are not likely to be unit tests strictly speaking. It also seems that people often, though not always, have *these* tests in mind when they brag about the tests that their type system saved them from writing. I wonder if people are talking past each other when they argue about types and tests because they have different tests in mind.<br /><br />To turn this into a question: Do you think your thesis that types and tests are complementary gets weaker when we start to consider tests that aren't pure unit tests? Do you think some people making claims about types as a replacement for some tests have different kinds of tests in mind (i.e., not unit tests) than the ones you're talking about in this post?Chris Younghttp://chrisyoung.netnoreply@blogger.com