Skip to content

Year: 2017

Trying to provide helpful pull request reviews

Posted in Building future-proof software

How I unblocked a frozen pull request

A few weeks ago, I saw a pull request to modify one of our web jobs which codebase is pretty old and had no tests. The pull request had no tests either. The thing is that we decided to make unit testing mandatory for any pull requests a couple of weeks before.

I started reviewing the code when I noticed someone else already posted a review. A pretty laconic “please add tests”. Not a bad nor a mean review but not a really helpful one. Proof of it is that it was posted about an hour before and the pull request was blocked. Indeed we do not untested logic to enter or remain in our software. Yes, it is aligned with our new policy about tests. That being said, the web job code was tightly coupled and pretty impossible to test as it was.

Monster release, you’re welcome – Poetry time

Posted in Poetry time: Bursts of poems

I like to write poems sometimes, even though I didn’t in ages. Also, I think I never posted any here. I hope you enjoy it,  please note that any resemblance to real persons, living or dead is purely coincidental.

Once upon a time a project manager
Decided to venture in a zone of danger
Little did he know was going to trigger a monster
Due to choices that none should ever foster
Because planning is not his comfort zone
He had to come to deal with me like Al’ Capone

My Musketeers for DotNet Test driven development

Posted in Building future-proof software, and Productivity

Test, four letters, one meaning and for some people a struggle. Getting people around you to write tests is easy only when everyone already agrees with you. As often, there are instances where some people show resistance to writing tests. Here is the stuff I hear the most from them:

D: I don’t have time to write tests.

A: I don’t need to test this.

B: I can’t write a test for this.

Simple continuous integration with Appveyor and Newman

Posted in Building future-proof software, Productivity, and Tutorials

Last month, I posted about Postman enabling you to test your APIs with little effort so that you can build future-proof software. Here we are going to cover setting up continuous integration for a simple project by using Newman to run your Postman collections. You may have heard about continuous integration in the past. Most commonly, continuous integration will build software from one’s changes before or after merging them into the main codebase. Even though there is an infinity of tools that allow implementing continuous integration, I will focus on Appveyor CI. In order to make things simple, I will create a very basic web API project and will host it on GitHub.