If you are developing a new product or a feature nearly from scratch and you are wondering if you should spend time writing UTs. You are probably thinking the right thing. (IMHO, if you think that you should always write UTs, you might be wasting a lot of time)
Let me try to keep this short and crisp:
- Typically if you are developing something new where features will keep getting added, subtracted really fast. You might realize that the core components might have to change. And not just change but might also vanish and new design components might also appear.
- So now your product is ready to go to the market and you just deployed your app on one of the hosting providers out there and you are now facing scaling issues – your app hangs when the traffic is on peak, you get 1000s of errors in the peak traffic time, your app is a memory hog and the GC runs a little too much. All of this is happening and you are thinking of major strategic design changes to make your code light-weight and stable.
- Your product is now out there, does not hang too often. But you still see tons of errors in the logs.
Depending on how many surprises you are expecting in stage 1,2 and 3, you should delay writing UTs in the initial phases of the launch of your new app / feature.
And how many surprises you expect depends on how new is the app you are going to launch, in terms of the core design components, the kind of traffic its going to receive, the new features that you expect to go in and out in the initial launch phase.
I have had experience where we ended up writing lot of UTs while we were in phase 1 and then it became harder and harder to maintain the UTs sanity during 1,2. We realized that the kind of speed with which the design was evolving was a little too much to keep the UTs sane.
Once your app has crossed stage 3, you know you should start adding UTs for sure. At the same time be really careful, the later you start with the UTs the bigger would be the overhead of making a solid UT framework stand from ground-up. To be honest, there is never too late for writing UTs, but there surely is too early, so understand your app and make your judgement call.
If you own a software/hardware deployment which serves your customers and the availability of your system is of high importance, here are the 5 things you can’t afford to miss out as far as monitoring your system health is concerned.
While this is no guide on how to setup monitoring, this definitely is a very quick and crisp check-list on bare minimum steps you MUST take achieve reliable monitoring of your system.
- Monitor your system’s availability through external pings. As an example, if you have an http based service, configure your monitoring system to hit your most important URLs at a particular interval and look for the response content and also make sure that the response is returned within a given time limit. You should know which are the URLs which represent your application’s availability and are nearly mutually exclusive. This monitoring shows you how the external world perceives your application/server.
- Monitor your system’s internal health through monitoring agents sitting on your machines. This would include basic hardware metrics around CPU, Memory, I/O, Disk Space, Network activity, no. of processes etc and application specific metrics like – error counts in your application logs, no. of requests, process health etc. While the external pings may be looking green, there may be something cooking internally which can hamper the external availability if not stopped.
- Monitor your monitoring system’s availability through external pings. This one is special. People generally tend to miss this one out. What if your monitoring system go down? Will you get alert emails / smses if your application goes down when your monitoring system had crashed ? If you don’t have external monitoring on the monitoring system itself, you are playing a lot on luck. In such a scenario, what you could do is to deploy a alternate system monitoring your application’s health. So if your primary monitoring system is down – most probably your secondary monitoring system would be up. So you have to have a secondary monitoring server, which would monitor either the primary monitoring system OR the application itself.
- Clearly differentiate between critical and warning alerts. When you get an alert you should know how severe it is. If you can afford to ignore the alert for the next 2-4 hours, its probably a warning. If you are losing(or may lose) business every second you ignore the alert you can call it critical. This is just a high level guideline, you should decide whats critical for you and whats not.
- Configure Instant notifications on your mobile for critical alerts.Your system might go down in the night when you are sleeping, it may go down on a Sunday or any other time when you are not checking your mailbox every 10 mins. If you really want a solid reliable monitoring system, this one is a super must.
While the above list is meant for your applications/server, you can easily relate the above strategy to monitor your own self as a leader .