{"id":2193,"date":"2013-11-25T13:09:31","date_gmt":"2013-11-25T01:09:31","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=2193"},"modified":"2013-11-25T16:39:25","modified_gmt":"2013-11-25T04:39:25","slug":"dunit-compatibility-in-smoketest","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/2193\/","title":{"rendered":"DUnit Compatibility in Smoketest"},"content":{"rendered":"[Estimated Reading Time: <\/span> 3<\/span> minutes]<\/span><\/span>

To address some odd concerns about differences between DUnit<\/strong> and Smoketest<\/strong>, I thought it would be useful to demonstrate how it is entirely within the gift of a Smoketest<\/strong> user to create their own “comfort” layer, to make using Smoketest<\/strong> more similar to the DUnit<\/strong> framework if they wish (though why in that case they wouldn’t simply use DUnit<\/strong>, I can’t quite fathom. But still).<\/p>\n

<\/p>\n

Interfaces vs<\/del> and Inheritance<\/h2>\n

The great thing about Delphi<\/strong> is that when a class implements an interface<\/strong> any derived classes inherit<\/em> that implementation. Even better, if you implement the interface methods virtually, then those derived classes can override the implementation without having to redeclare the interface<\/em>.<\/p>\n

So, if you really don’t like the idea of declaring and implementing interfaces to provide Setup<\/strong> and Cleanup<\/strong> methods on TTestCase<\/strong> derived classes you have a very simple remedy:<\/p>\n

Implement your own class from which to derive your test cases and have this provide default, no-op, virtual implementations of these framework hooks, just as the DUnit<\/strong> test case base class does for the virtual methods it relies on.<\/em><\/p>\n

If it really bothers you that<\/em> much, you can even take this opportunity to replace the framework Cleanup<\/strong> method with a virtual TearDown<\/strong> method in it’s stead.<\/p>\n

Heck, if you really want to write CheckEquals()<\/strong> for your test and then describe it separately, you can even provide that<\/em> in your DUnit<\/strong> comfortable compatibility class. You can even have the CheckEquals()<\/strong> method always “fail early”, just like DUnit<\/strong>.<\/p>\n

You might end up with something like this:<\/p>\n

\r\n  type\r\n    TDUnitTestCase = class(TTestCase, ISetupTestCase,\r\n                                      ICleanupTestCase)\r\n    protected\r\n      procedure Setup; virtual;\r\n      procedure Cleanup;\r\n      procedure TearDown; virtual;\r\n      procedure CheckEquals(aResult: Boolean; aMsg: String = '');\r\n    end;\r\n\r\n\r\n  procedure TDUnitTestCase.Setup;\r\n  begin\r\n    \/\/ NO-OP - just like mother used to make\r\n  end;\r\n\r\n  procedure TDUnitTestCase.Cleanup;\r\n  begin\r\n    TearDown;\r\n  end;\r\n\r\n  procedure TDUnitTestCase.TearDown;\r\n  begin\r\n    \/\/ NO-OP - the comfort of the familiar\r\n  end;\r\n\r\n  procedure TDUnitTestCase.CheckEquals(aResult: Boolean; aMsg: String);\r\n  begin\r\n    Test(aMsg).Expect(aResult).IsTRUE.IsShowStopper;\r\n  end;\r\n<\/pre>\n
You could even implement the same pattern for the project and method specific setup and cleanup hooks.  DUnit<\/strong> doesn’t have these so doesn’t provide a “specification” to comply with in this area, but you would presumably choose to follow the same virtual method pattern that DUnit<\/strong> adopts for the test case setup\/teardown.<\/p>\n
Why Not Just Copy DUnit ?<\/h2>\n
Some people don’t seem to understand why I didn’t simply mindlessly copy DUnit<\/strong>, thus making such adaptations unnecessary.<\/p>\n
The thing is, I didn’t implement Smoketest<\/strong> with compatibility with DUnit<\/strong> in mind.  Quite the opposite.  I didn’t like<\/em> the way DUnit<\/strong> worked!  Little wonder then that Smoketest<\/strong> works differently!<\/p>\n
I like to think however that the approach I took demonstrates it’s benefits no more obviously than when considering the ease with which it is possible to build such alternative API’s on top of the framework without having to resort to modifying the framework itself.<\/p>\n
I imagine – though I have not tried – that you could even contrive to make such a compatibility layer so seamless and complete that an existing DUnit<\/strong> project would compile directly against Smoketest<\/strong> with only the slightest of changes, primarily around not having to explicitly state which “runner” you are using, since in Smoketest<\/strong> this is governed by the project compiler settings\/directive directly (console vs GUI app) without the need for parallel changes to the project source code.<\/p>\n
In the case of DUnit<\/strong>, it was impossible to achieve the changes in the test writing experience that I desired; you cannot reduce<\/em> the visibility of inherited members, so with any pattern that relies on visibility of certain inherited class members you are stuck with the choices made in the implementation of the base class.<\/p>\n
Smoketest<\/strong> doesn’t paint you into this particular corner.<\/p>\n
For people – such as myself – who don’t like DUnit<\/strong>, Smoketest<\/strong> exists precisely to offer a choice.  A choice albeit initially only I was making (in the sense of deciding how my preferred alternative would work differently).<\/p>\n
If someone doesn’t like the choices I<\/em> made it seems to me they themselves have a choice:  They can – with a modicum of thought and a minimum of effort – add a layer of comfort that they will find acceptable.  Or they can choose simply not to use Smoketest<\/strong>.<\/p>\n
I<\/em> would not presume to tell them<\/em> what choice they<\/em> should make.  \ud83d\ude09<\/p>\n","protected":false},"excerpt":{"rendered":"
[Estimated Reading Time: <\/span> 3<\/span> minutes]<\/span><\/span> To address some odd concerns about differences between DUnit and Smoketest, I thought it would be useful to demonstrate how it is entirely within the gift of a Smoketest user to create their own “comfort” layer, to make using Smoketest more similar to the DUnit framework if they wish (though why in that case they […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[4],"tags":[292,50,51],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-zn","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":2177,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2177\/","url_meta":{"origin":2193,"position":0},"title":"Smoketest – Interfaces vs Inheritance","date":"22 Nov 2013","format":false,"excerpt":"A couple of commenters on my previous post have taken issue with my use of interfaces to form contracts between test cases and the test framework, rather than using simple virtual methods and inheritance as found in DUnit. I thought it would be interesting to illustrate why I went down\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Screen-Shot-2013-11-22-at-09.02.29.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":2164,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2164\/","url_meta":{"origin":2193,"position":1},"title":"Smoketest – Some Differences With DUnit","date":"19 Nov 2013","format":false,"excerpt":"Writing tests in Smoketest is intended to enable a test developer to write tests in a way that describe themselves, without requiring the test developer to add this \"narrative\" themselves. To see this in action, I thought I would compare some simple DUnit tests with the equivalent using the Smoketest\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":2169,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2169\/","url_meta":{"origin":2193,"position":2},"title":"Smoketest – Set Me Up \/ Tear Me Down","date":"20 Nov 2013","format":false,"excerpt":"In a previous post I demonstrated how the default \"pretty name\" for a Smoketest test case (derived from the test case classname) can be over-ridden by a test developer by implementing a specific interface (INameCase) on the test case class itself. There are some other interfaces that can be implemented\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":263,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/263\/","url_meta":{"origin":2193,"position":3},"title":"Exchange() – Epilogue and Smoketest","date":"28 Aug 2008","format":false,"excerpt":"A colleague of mine directed me to a further minor refinement of the 'final' Exchange() code I posted the other day. The change is minor but yields a worthwhile performance improvement, but my main reason for bothering to post (yet!) another update is an excuse to introduce the testing framework\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/exchange_after-295x300.gif?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":2095,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2095\/","url_meta":{"origin":2193,"position":4},"title":"Extending Smoketest (Part 1) – An Inspector Calls","date":"05 Nov 2013","format":false,"excerpt":"In the soon to be released Smoketest framework it is sometimes useful to create new test types to supplement the tests built-in to the framework. In this and the next post I will walk through the process of implementing and registering a custom test with the Smoketest framework. In a\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":2111,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2111\/","url_meta":{"origin":2193,"position":5},"title":"Extending Smoketest (Part 2) – Great(er) Expectations","date":"07 Nov 2013","format":false,"excerpt":"In my previous post on Smoketest I showed how you can extend the inspections framework to work with complex types in your code. As promised, I shall now show how you can do much the same thing to extend the framework with entirely new tests. \u201cI must be taken as\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2193"}],"collection":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/comments?post=2193"}],"version-history":[{"count":8,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2193\/revisions"}],"predecessor-version":[{"id":2201,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2193\/revisions\/2201"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=2193"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=2193"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=2193"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}