Unit Tests is one of those things everybody’s talking about, but few have time to actually create. Every time I’ve been in a job interview, I’ve been asked if I am willing to create Unit Tests, and given the impression that if I answered no I’d not be chosen - Still, every time I’ve started the job I’ve been told the following …
Unit Tests, we don’t have time to write non-productive code
Some companies of course are different, but the majority of companies I’ve worked for as an enterprise software developer have told me to not “waste time” on writing unit tests. This approach of course is pure madness, but it’s still the reality. Realising the serious implications of this we created the ability to have Magic automatically create unit tests for you, by simply clicking a button. In the viewo below I am demonstrating how this works.
As you’re invoking your HTTP endpoints, Magic will actually remember your payload, arguments, the response, status code, etc - And once you click the “New assumption” button allow you to persist the invocation, for then to later being able to “replay” the invocation. This allows you to create a suite of HTTP endpoint invocations, you can collective replay later in some few seconds, to sanity check your system, and verify it’s healthy and behaving as expected. Below is a screenshot illustrating a persisted HTTP invocation.
To create such asumptions, all you need to do is to invoke your HTTP endpoint, and click the “New assumption” button as illustrated below, at which point you can provide a description for your assumption, in addition to a name which Magic will refer to it as later.
If you click the “Match response” checkbox, Magic will assume future invocations returns an exact match of the original HTTP response object. If you leave it off, it will only verify the status code. For endpoints returning dynamic data, you should for obvious reasons not click the checkbox. However, more important is the fact that Magic also allows you to replay error invocations, implying invocations that should return some sort of error object to the caller. Examples could for instance be trying to login without a username or password - Which should obviously result in some sort of error response. Magic also allows you to manually create assumptions by creating Hyperlambda code by hand, that becomes a part of your unit test suite, for cases where your logic is too complex for the automated unit test generator to automatically do the work. You can read more about assumptions here where you can see examples of the latter.