Developing with a Test First Approach

I spent this week kind of sluggishly finishing up PRs that were close to completing such as the version on the banner. We can now see what the latest commit Telescope is running now by clicking on the version.

Another one I finished up since last release was configuring Nginx to use recommended settings by Mozilla.

Yes, I am still neglecting Kubernetes...

However, today I'm here to write about an issue I just took on and started working on at 2AM this morning, Issue-908 and I think I am close to finish. This work involved Redis, which was nice as some of my earliest contributions to Telescope were Redis related issues.

For this PR I took a different approach, put a heavy emphasis on thinking about and writing tests, I quickly wrote new features that should have mostly worked and used the tests I wrote to aid in making sure they are mostly correct. Up to this point, I haven't really written much tests, I have maybe modified existing tests. So this time I made sure I wrote a ton of tests to cover situations and from there working on the new features so that whatever I am expecting and what I'm actually receiving match. 

The approach was refreshing, instead of having to console.log() things, the tests easily told me what they were doing or what the value being returned was. For example as part of this PR I had to create a function that removes the Feed and all its associated Posts, some people might write a test that adds two posts belonging to a feed, delete the feed and check whether the posts still exist in the database.

Here's what I did:

1. Create the feed for the test, make sure the created feed has the same values I used to create the feed.
2. Create two posts, make sure the created posts' data have the same values I used to create the posts.
3. Remove the feed, make sure the removed feed doesn't return any thing, check if both posts are empty too.

Is this test perfect? Probably not, there may or may not be some edge cases I haven't though of yet. Is this overkill? I have no idea, but more is probably better in this case. Will I write more tests in the future as long as it is not in the front-end? You bet. With all these tests, if any of them start failing, I can probably pinpoint where the code went wrong, instead of playing a guessing game.

Be responsible, write tests!