Update - commenters pointed out an obvious mistake - I should have kept the sample code here the same as my real code. I've updated the code samples. Some time ago I asked why unit tests use assertions instead of returning a boolean. I didn't get any particularly convincing answers, so I continued returning a boolean, in my home-grown test framework, that's so small it hardly deserves the name 'framework'. One obvious benefit from using exceptions is that you get the name of the test method and class in the exception output. In my framework, I had to explicitly supply that. Each test object had a getName(). return "TestUninstallingDrivers". Ok, now I have duplication:
public static final UnitTest testUninstallingDrivers=
new UnitTest()
{
public boolean test()
{
stuff..
return !card.hasDrivers();
}
public String getName()
{
return "testUninstallingDrivers";
}
};
public static final UnitTest $x=new UnitTest()
{
public boolean test()
{
//Auto-generated method stub. To stop this
//annoying message, go through some dialogs
//that you never really wanted to anyway.
return false;
}
public String getName()
{
return "$x";
}
}
unitTest(testUninstallingDrivers,
{
stuff..;
return !card.hasDrivers();
})
template unitTest(name,body)
{
public static final UnitTest <name>=new UnitTest()
{
public boolean test()
{
<body>
}
public String getName()
{
return "<name>";
}
}
};
6 comments:
Why not just use $x.class.getSimpleName() ?
Dude...... you know you can call getClass().getName()
.. right? This works on 100% of the IDEs.
Hi Ricky,
I find it surprising that you have an interest in testing, but reject the use of sound type systems. Type systems ideally eliminate the need for testing altogether. Of course, this ideal is seldom met, even in Haskell (see Coq or Epigram for cases where it is met), where automated specification-based testing is far superior to the "assertion-based" (i.e. explicitly selecting a case from the domain).
You might want to take a look at QuickCheck or, with a touch of my bias, ScalaCheck (of which I am a committer).
You're right, I could use getClass().getName(). I got bitten by making my sample code look more conventional. My real code looks more like this:
public static final UnitTest testInstallingDrivers=new UnitTest(){anonymous class here};
There's no way of grabbing the name testInstallingDrivers at runtime from inside the instance of UnitTest there.
dibblego,
I have an interest in both. I've said on a few occasions that when you find yourself writing more test code than production code, it's likely that you're trying to prove through testing, which is usually nigh-on impossible. In those cases, you should prove through, well, proof.
Where you and I disagree is that you think the proof must be there before the code can be legitimately executed, and Haskell's compiler agrees with you. I'm happy to run code that I haven't thought through the types of yet, and then if I need some assurances that it is correct, I can add types and hence construct a proof later.
I haven't met the ideal language for this yet, though.
Ricky,
That is not exactly my position, but I want pursue it here.
I am wondering (hoping) that this quote from wikipedia might open you to other possibilities:
Traditionally, typed lambda calculi were seen as refinements of the untyped lambda calculus. A more modern view considers typed lambda calculi the more fundamental theory, and untyped lambda calculus a special case with only one type.
...
System F allows polymorphism by using universal quantification over all types; from a logical perspective it can describe all functions which are provably total in second-order logic.
Post a Comment