{"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_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[4],"tags":[261,51],"class_list":["post-2177","post","type-post","status-publish","format-standard","hentry","category-delphi","tag-deltics","tag-smoketest"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-z7","jetpack_sharing_enabled":true,"jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2177","targetHints":{"allow":["GET"]}}],"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}]}}