loading...

Creating PULSE — A developer-friendly server monitoring tool (Part 10)

mattkingshott profile image Matt Kingshott 👨🏻‍💻 Originally published at Medium on ・4 min read

Facebook’s Prineville Data Server Center

Creating PULSE — A developer-friendly server monitoring tool (Part 10)

This is part of a weekly development blog series, where I will document the creation of an application from the initial idea through to its deployment on a scalable architecture. Even as an experienced developer, I find these stories to be interesting and I usually pick up a tip or two, so if you’d like to come along, and hopefully benefit in some way, let’s dig in!

NOTICE : Pulse has now launched and is available to use. You can create an account by visiting https://pulse.alphametric.co

Introduction

I feel the need to point out that this article is less so about the development of Pulse, and more about testing in general. I’ll be talking about the type of testing used in Pulse, but also why it’s important and how it helps your sanity.

The essential final step

Ah, testing, the often overlooked element of a solid application. Back in the day, testing used to be an afterthought, or worse, absent entirely! Personally, as a developer who often builds apps solo, I can’t get enough automated tests. They allow me to sleep at night as, if I make a change, I can discover in an instant whether anything in my application no longer works.

Yes, it’s true, they are a pain to write. They’re time consuming and they delay your progress in developing the app, but they’re vital nonetheless and in this day and age, only an amateur would choose to skip building automated tests.

So, with that in mind, let’s dive in…

Testing comes in threes

Your tests generally fit into layers of depth. At the deepest level, is the unit test, which examines code in a specific class, often even just a method.

When your tests begin to cross multiple classes or involve making requests directly to your application’s routing component, you’re at what I like to call the feature test (the terminology varies across the industry, but its basically the same regardless of what name is being used).

For some people, especially backend developers, that’s the end of it, but given how complex our web applications have become with frontend JavaScript libraries like Vue and React, I also take advantage of browser-based testing via the truly awesome Laravel Dusk package.

How many tests should I write?

There is no set answer to this, but generally, a good philosophy is to write as many tests as you require to satisfy the "it works" criteria.

Some people go totally over the top and end up with thousands of tests that are extremely superficial e.g. a class property can be set. If this functionality is already covered by another test, there’s usually no need to duplicate it.

A second thing to remember, is that unit tests should make up only a small percentage of your test suite. Why? Because users don’t execute one method in your app, they execute a workflow involving many separate steps. Instead, focus on writing feature and browser tests wherever possible.

As a reference point, Pulse contains 164 unit / feature tests and 53 browser tests. These tests ensure the feature set works. They don’t handle all possible edge cases, but that’s okay…

You can never test everything!

Instead, respond to problems when they occur. Otherwise, you’ll just be writing tests forever and you’ll never release your product.

How different should the tests be?

Well, let’s answer that with some examples. We’ll begin with a good example of a unit test. The User model has a method called isCustomer(), which checks to see if the user’s role type is that of a customer:

A unit test

See how the test is short and to the point? It does the absolute minimum to confirm functionality and nothing else.

Now, let’s look at a feature test. In this case, we need to be able to confirm that a user can generate a fresh API token if they need to:

A feature test

Notice how the test is more involved / feels like an actual user’s workflow. We sign in and send a post request to a url, then we check we’re redirected and get a flash message. Lastly, we confirm the token has indeed changed.

Finally, for the browser test, we’ll examine a test that does the same thing. However, we’re not testing the SAME workflow. Instead, we’re testing that the user can physically use the application to execute the workflow:

A browser test

The other justification for tests

Beyond confirming that the application works as expected, these tests also serve as a form of documentation for other developers. They can view the tests and see how the various classes & methods work together to accomplish a given task, such as allowing a user to change their API token.

Wrapping Up

Well, that’s it for this week. My apologies if you were hoping for something more expansive, but the truth is, without dumping huge amounts of code onto the page, it would be difficult to really dig in much further.

Hopefully, if nothing else, I’ve reassured you that Pulse is well taken care of in the testing department and a safe product to use for your infrastructure!

Next up, we’ll be taking a look at the process of rolling Pulse out for its beta. It might be a couple of weeks before this happens, but have no fear, it will be documented! So, if you haven’t already, be sure to follow me here on Medium, and also on Twitter for more frequent updates.

NOTICE : Pulse has now launched and is available to use. You can create an account by visiting https://pulse.alphametric.co

Thanks, and happy coding!

Posted on Sep 9 '19 by:

mattkingshott profile

Matt Kingshott 👨🏻‍💻

@mattkingshott

Founder. Developer. Writer. Lunatic. Created Pulse, IodineJS, Axiom, and more. #PHP #Laravel #Vue #TailwindCSS

Discussion

markdown guide