Comments on: On unit testing and type checking http://blog.tupil.com/on-unit-testing-and-type-checking/ (Get up early, code often) Mon, 08 Feb 2010 22:03:01 +0100 http://wordpress.org/?v=2.8.4 hourly 1 By: sakthi http://blog.tupil.com/on-unit-testing-and-type-checking/comment-page-1/#comment-10115 sakthi Tue, 30 Jun 2009 08:20:55 +0000 http://blog.tupil.com/?p=44#comment-10115 HI.. Good Article... I like to use both unit testing and strong static typing both at the same time, checking for different things. I had read another Article in this topic from macrotesting www.macrotesting.com had explained it in a different way but your article is so clear and easy to understand. Thank you .... Cheers sakthi HI..

Good Article…

I like to use both unit testing and strong static typing both at the same time, checking for different things. I had read another Article in this topic from macrotesting http://www.macrotesting.com had explained it in a different way but your article is so clear and easy to understand. Thank you ….

Cheers
sakthi

]]> By: Reinier Lamers http://blog.tupil.com/on-unit-testing-and-type-checking/comment-page-1/#comment-1517 Reinier Lamers Tue, 28 Oct 2008 00:22:34 +0000 http://blog.tupil.com/?p=44#comment-1517 Great insight! Still I like to use both unit testing and strong static typing both at the same time, checking for different things. When I code in C# or Haskell, the type checker checks for stupid mistakes where I have not clearly expressed my toughts in the programming language, while the unit tests try to find cases that I have forgotten to pay attention to when thinking about the problem. Great insight!

Still I like to use both unit testing and strong static typing both at the same time, checking for different things. When I code in C# or Haskell, the type checker checks for stupid mistakes where I have not clearly expressed my toughts in the programming language, while the unit tests try to find cases that I have forgotten to pay attention to when thinking about the problem.

]]> By: Chris Eidhof http://blog.tupil.com/on-unit-testing-and-type-checking/comment-page-1/#comment-1441 Chris Eidhof Fri, 24 Oct 2008 12:14:58 +0000 http://blog.tupil.com/?p=44#comment-1441 Paul: yes, that's completely true. However, the types of theorems you can state depend on your type-system. For example, it's not trivial in Haskell to state that an append of two lists xs and ys yields a list with length = length xs + length ys. With unit-tests this is easier to test, and with dependent types you can even do that in your type system. So in a way, they provide you with the ultimate Curry-Howard isomorphism. Paul: yes, that’s completely true. However, the types of theorems you can state depend on your type-system. For example, it’s not trivial in Haskell to state that an append of two lists xs and ys yields a list with length = length xs + length ys. With unit-tests this is easier to test, and with dependent types you can even do that in your type system. So in a way, they provide you with the ultimate Curry-Howard isomorphism.

]]> By: Paul Johnson http://blog.tupil.com/on-unit-testing-and-type-checking/comment-page-1/#comment-1436 Paul Johnson Fri, 24 Oct 2008 10:35:59 +0000 http://blog.tupil.com/?p=44#comment-1436 Actually it goes deeper than that. The Curry-Howard Isomorphism says that a function type is equivalent to a theorem, and the implementation of the function is equivalent to a proof of that theorem (see Wikipedia for more info). Hence writing down the type of a function is the first step to writing a formal specification, and the more precise your type definitions, the more precise your specification will be. On the other hand the test-driven-development approach uses point test data as a semi-formal specification. And of course Haskell QuickCheck and its relatives use a formal specification of the function to generate random test data and verify that the results are correct. Actually it goes deeper than that. The Curry-Howard Isomorphism says that a function type is equivalent to a theorem, and the implementation of the function is equivalent to a proof of that theorem (see Wikipedia for more info). Hence writing down the type of a function is the first step to writing a formal specification, and the more precise your type definitions, the more precise your specification will be.

On the other hand the test-driven-development approach uses point test data as a semi-formal specification. And of course Haskell QuickCheck and its relatives use a formal specification of the function to generate random test data and verify that the results are correct.

]]> By: Sjoerd Visscher http://blog.tupil.com/on-unit-testing-and-type-checking/comment-page-1/#comment-1423 Sjoerd Visscher Thu, 23 Oct 2008 20:55:13 +0000 http://blog.tupil.com/?p=44#comment-1423 At Xopus we have finally started to use unit testing too. The unit tests are now even run automatically when you commit, and if you break a test, an e-mail will be sent to the person who broke the trunk. It works really great. For my own hobby programming language I'm thinking about using unit tests as the only way to specify interfaces. Types are usually not enough to describe the relation between behavior of functions. With unit tests those relations are lot easier to express. At Xopus we have finally started to use unit testing too. The unit tests are now even run automatically when you commit, and if you break a test, an e-mail will be sent to the person who broke the trunk. It works really great.

For my own hobby programming language I’m thinking about using unit tests as the only way to specify interfaces. Types are usually not enough to describe the relation between behavior of functions. With unit tests those relations are lot easier to express.

]]> By: BONUS http://blog.tupil.com/on-unit-testing-and-type-checking/comment-page-1/#comment-1422 BONUS Thu, 23 Oct 2008 20:39:20 +0000 http://blog.tupil.com/?p=44#comment-1422 Man, great post! I've been thinking about that too, I just haven't found the words to express it as eloquently and clearly as you did. In pure functional programming, each function usually does something meaningful on its own by default. In imperative languages, functions and methods sometimes just push some state around or something and don't do anything meaningful on their own. And once they're refactored, they look more like their pure functional counterparts. Man, great post! I’ve been thinking about that too, I just haven’t found the words to express it as eloquently and clearly as you did. In pure functional programming, each function usually does something meaningful on its own by default. In imperative languages, functions and methods sometimes just push some state around or something and don’t do anything meaningful on their own. And once they’re refactored, they look more like their pure functional counterparts.

]]> By: Erik Hesselink http://blog.tupil.com/on-unit-testing-and-type-checking/comment-page-1/#comment-1420 Erik Hesselink Thu, 23 Oct 2008 18:45:45 +0000 http://blog.tupil.com/?p=44#comment-1420 I guess the Haskellers using QuickCheck (or SmallCheck, etc) are really building top-notch software then! :) I guess the Haskellers using QuickCheck (or SmallCheck, etc) are really building top-notch software then! :)

]]>