{"id":2177,"date":"2013-11-22T08:38:25","date_gmt":"2013-11-21T20:38:25","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=2177"},"modified":"2013-11-22T09:01:04","modified_gmt":"2013-11-21T21:01:04","slug":"interfaces-vs-inheritance","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/2177\/","title":{"rendered":"Smoketest – Interfaces vs Inheritance"},"content":{"rendered":"[Estimated Reading Time: <\/span> 4<\/span> minutes]<\/span><\/span>

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<\/strong>. I thought it would be interesting to illustrate why I went down this route.<\/p>\n

<\/p>\n

It is suggested that using inheritance means that discovering the methods required to be implemented to support Setup<\/strong>\/TearDown<\/strong> in DUnit<\/strong> is simpler than having to know the required interface name and then having to lookup the method signature involved, as in the case of Smoketest<\/strong>.<\/p>\n

This of course assumes that documentation either does not exist or is being wilfully ignored.<\/p>\n

First of all, the interfaces in Smoketest<\/strong> are designed to be highly memorable. They read as a natural description of a behaviour that a test case class follows.<\/p>\n

Where a test case has some project setup to perform it states “I Setup (the) Project<\/em>“. If it has some setup to perform specific to the test case “I Setup (this) Test Case<\/em>“. And so on.<\/p>\n

So remembering the interface name really shouldn’t be hard, since it describes what you wish to achieve. Whether you intuit the interface name, select it from the fairly short list of interfaces offered by IDE Code Completion, the chances are you will only have to look it up once.<\/p>\n

The compiler then ensures that the contract is fulfilled.<\/p>\n

So let’s assume you at least know the interface involved and look at the impact that using the interface has on finding the method(s) required, as compared to finding the method from the list of inherited methods.<\/p>\n

First, let’s look at what the IDE offers when we invoke Code Completion<\/strong> in the class declaration of a DUnit<\/strong> test case.<\/p>\n

\"Page<\/a>
Page 1 of 3<\/figcaption><\/figure>\n

I made my suggestion list popup as big as I possibly could, but they aren’t on even the first page of this greatly enlarged list so scrolling down to the next complete page of suggestions ….<\/p>\n

\"Page<\/a>
Page 2 of 3<\/figcaption><\/figure>\n

Aha – there they are. Setup<\/strong> and Teardown<\/strong>. Look carefully, you will see them eventually.<\/p>\n

Of course, to find them you have to already know what you are looking for since they are simply listed alphabetically among all the other methods that you have no intention of implementing yourself.<\/p>\n

I don’t see any methods for performing per-test or project-wide setup\/teardown though, so I am not entirely sure of the context in which Setup<\/strong> and Teardown<\/strong> operate. I guess I’ll have to read the documentation after all. \ud83d\ude42<\/p>\n

Now let’s look at the same Code Completion<\/strong> offering for a Smoketest<\/strong> test case class declaration:<\/p>\n

\"TOP<\/a>
TOP OF THE BILL!<\/figcaption><\/figure>\n

Well, would you look at that. The methods introduced by my specified interface contracts (in this case, that I will provide a name for the case and that I perform some test case setup), are put front and centre.<\/p>\n

Now, without the interfaces declared on the class, I would see no such methods at all. But is this really a problem ? I don’t think so. The list of available methods is itself much shorter and the complete lack of any setup\/cleanup methods will itself remind me that I have to form my contract with the framework first.<\/p>\n

And I then get to choose which<\/strong> contract – setting up specific test methods, the test case or project wide setup (and\/or attendant cleanup).<\/p>\n

On that note, issue has also been taken with the use of “Cleanup<\/em>” rather than “TearDown<\/em>” in the method and interface names. This was deliberate. TearDown<\/strong> has a finality about it that seemed to be most often not appropriate.<\/p>\n

Take for example the JSON test case which performs some cleanup after every test method by clearing a JSON object in preparation for the next test method. This really isn’t “tearing anything down”. It really is<\/strong> just “cleaning up”.<\/p>\n

Sometimes your cleanup will<\/em> involve completely destroying some artefacts used\/created during testing, but this is just one extreme form of cleanup.<\/p>\n

When the house-work needs doing, do you tear down your house or do you clean it up ?<\/p>\n

Even tearing down the house, if\/when it ever becomes necessary, is only what you do in order to “clean” the site, in readiness for a new house to be built.<\/p>\n

TearDown<\/strong> may appeal to some people’s sense of the dramatic, but other than that it is actually a very poor choice of name imho.<\/p>\n

I didn’t create Smoketest<\/strong> in order to simply create a plug-compatible alternative to DUnit<\/strong>. I didn’t even create it as a “competitor” for DUnit<\/strong>. I created it for myself precisely because I didn’t and don’t like the way DUnit<\/strong> works.<\/p>\n

And because DUnit<\/strong> didn’t and doesn’t do some things that I wanted and needed (see my next post).<\/p>\n

I simply choose now to share it.<\/p>\n

If you do like the way DUnit<\/strong> works you are of course more than welcome to continue using it, but don’t expect Smoketest<\/strong> to conform to any expectations you might bring from that other framework. \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"

[Estimated Reading Time: <\/span> 4<\/span> minutes]<\/span><\/span> 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 this route.<\/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":[261,51],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-z7","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":2193,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2193\/","url_meta":{"origin":2177,"position":0},"title":"DUnit Compatibility in Smoketest","date":"25 Nov 2013","format":false,"excerpt":"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\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":2164,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2164\/","url_meta":{"origin":2177,"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":2177,"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":2111,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2111\/","url_meta":{"origin":2177,"position":3},"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":[]},{"id":2006,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2006\/","url_meta":{"origin":2177,"position":4},"title":"Blowing Smoke…","date":"01 Nov 2013","format":false,"excerpt":"To alleviate the grind of polishing and sanitising my code (and, let's be honest, just plain 'fixing' it in some cases) ready for release, I have re-kindled my participation on Stack Overflow. In a happy confluence yesterday a question came up which allowed me to exercise one of the libraries\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"Ready to Run","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Screen-Shot-2013-11-01-at-09.00.33.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":2095,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2095\/","url_meta":{"origin":2177,"position":5},"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":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2177"}],"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=2177"}],"version-history":[{"count":5,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2177\/revisions"}],"predecessor-version":[{"id":2189,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2177\/revisions\/2189"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=2177"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=2177"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=2177"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}