The Personal Blog of a Geek in Arizona

Menu

Search

Test-Driven IT

You’ve probably heard of test-driven programming, where the first thing a developer writes is an automated test, not the actual program code. This way when the code is written, it can instantly and repeatedly be tested to see if it works.

Why not do the same in an IT department, or any other endeavor for that matter? If automated testing is available, it should be used as early as possible in the endeavor so that as soon as a working state is achieved effort can be diverted to polishing or new tasks instead of wasting more time “making it work” when it already does.

How many times have you as a technician been troubleshooting a connection issue, and realized the problem had been fixed for awhile but you didn’t notice? If your first step had been to set up automated pings or http connection tests, you might have saved a lot of time and frustration. Tools like Nagios and IPmonitor are well equipped for this task. If you know of any other good tools, leave a comment!

Just some food for thought. Get some visualization or results of what you’re working on if at all possible.

Advertisements

Like this:

LikeLoading...

Related

Post navigation

2 thoughts on “Test-Driven IT”

Harrysays:

That’s in some ways the holy grail of monitoring software. An IT shop that has their monitors setup in such a way that whenever a change occurs the tests pass or fail is a happy IT shop. Too often though people setup monitors that ping or maybe check to see that a particular port is listening and leave it at that. Good monitors need to poll your systems the same way your customers do. A few packages I’ve run into over the years that can do that include MS SCOM, HP Sitescope (formerly had a free version but not since bought by HP), Zabbix (currently free, but a pain to setup IMHO), WhatsUpGold, plus many others. The key seems to be finding a system that doesn’t rely too heavily on ping and SNMP. SNMP is great but cryptic as hell if you have to write your own mibs.

Another method I’ve resorted to in the past is to write your own tests. In windows, WMI can be your best friend. AutoIt automation macros can be used to test legacy GUIs that can only be tested in the GUI or with low level Win32 calls, and .NET has a ton of automation tools that can be used to script just about any test imaginable. Just write your test in .NET or shell scripts in Linux and have it output to html with a simple code like 0 or OK and something meaningful for error conditions . Then check the outputs with a free web scraper monitoring system like Zabbix.

Indeed, I’d like to find something closer to the holy grail as well. For web developers obviously scripting is a good choice, but for pure system/network people I think tools like IPMonitor do a great job of testing things like the contents of an HTML page or the size of a file. Only problem with IPMonitor is that it costs a fair bit of money.