Skip to main content

Posts

Showing posts from September, 2015

The Self Shunt - Test Doubles without a Framework

Generally you should favour hand crafted stubs without a framework by default. Before you reach for a framework there is another bridging step that you can take only pulling in a framework if complexity arises - the Self Shunt.Assume a simple Hello World subject under test where we can provide different formatters that format the message to a console, XML or JSON for example. How do we test that the formatter is used, with the right arguments?Enter the Self Shunt (pdf). Have the test fixture implement the interface aka assume the role of a message formatter. It provides itself as a parameter to the greeter in the form of self/this. The greeter uses this implementation during its execution, the test fixture can then assert or set state.BenefitsQuick and simple to get up and running.Most commands fall into the category of invoke something with some parameters, with little more complexity.Forces you to respect the Interface Segregation Principle, otherwise this technique can become painf…

Waste: Write Less Code

One of the biggest forms of waste is code. An estimated 80% of features in a software project are never or rarely used. This makes code the software development equivalent of inventory. Having a warehouse full of inventory is not a benefit, neither is having a repository full of code.How to Have Less Code?Delete it!As much as you can within reason of course, tests must pass and features must still work. Deleting feels great when you can successfully remove some legacy code. You'll be surprised at what can be removed. Commented out code, unused classes and methods are the obvious first candidates.Say No To Features by DefaultOnly add them if the benefit outweighs planning, designing, development, testing and maintenance costs combined. Even then, do you really need it? The advice here is do not listen to your customers regarding which features to add, instead listen to their problems.Libraries/FrameworksTry and see if a library or framework can handle your use case. They may not be…

Types of Test Doubles

Mock is an overloaded term in software development. Sadly this leads to developers answering with "mock it" when a mock object may not be the right solution. Test Doubles are a more general term. I should try to use this naming more than I do at present - a goal I aim to work towards. The result of choosing the wrong test double may seem innocent but the effect will be a very different style of test method, with increased coupling to implementation details. The following definitions are ordered in terms of complexity and increased coupling.StubsProvide canned responses. By their nature stubs would respond to queries. Stubs allow you to test paths of the code that would be otherwise difficult as they always provide the same answer.SpiesSimilar to a stub but with the addition that a spy records its actions. When responding to a query or a command the spy keeps track of what happened, how often and anything else relevant. The test can then inspect the spy for the answer, decidi…

Release It - Highlights Part 2

This is the second part of my collection of notes and snippets from Release It!Part 1 - Shared Resources, Responses, SLA, Databases and Circuit BreakersPart 2 - Caches, Testing, HTML, Pre-Computation and Logging (Future Post)CachesLow memory conditions are a threat to both stability and capacity.You need to ask whether the possible keys are infinite or finite and would the items ever need to change?The simplest cache clearing mechanism is time based.Improper use of caching is the major cause of memory leaks, which turn into horrors like daily server restarts.Your system should run for at least the typical deployment cycle. If you deploy once every two weeks, it should be able to run for at least two weeks without restart.Limit the amount of memory a cache can use.Caches that do not limit memory will eventually eat all memory.TestingEvery integration point should have a test harness that can be substituted.Make your test harness act like a hacker - try large payloads, invalid character…

Release It - Highlights Part 1

Release It! is one of the most useful books I've read. The advice and suggestions inside certainly change your perspective on how to write software. My key takeaway is that software should be cynical. Expect the worst, expect failures and put up boundaries. In the majority of cases these failures will be trigged by integration points with other systems, be it third parties or your own.My rough notes and snippets will be spread across the following two posts. There is much more to the book than this, including various examples of real life systems failing and how they should have handled the problem in the first place.Part 1 - Shared Resources, Responses, SLA, Databases and Circuit BreakersPart 2 - Caches, Testing, HTML, Pre-Computation and LoggingShared ResourcesShared Resources can jeopardize scalability.When a shared resource gets overloaded, it will become a bottleneck.If you provide the front end system, test what happens if the back end is slow/down. If you provide the back …