Testing

I’m writing up a new gem called Tinfoil that tests whether web servers support secure headers. Since this is a command-line interface (CLI) for a Unix-based system, I have a hard time testing the CLI in Ruby’s built-in Test::Unit framework. The problem is that the CLI outputs directly to STDOUT and STDERR, polluting my test output when I run them. The problem to this was solved by capturing stdout and stderr and redirecting them for a short time while the test runs. I got it from this StackOverflow answer, and I have added another method for capturing stderr. ...

I am in the process of consolidating a number of websites that I use into a smaller set of servers. This is partly being done to reduce costs as well as support less resources, but it also provides me with a chance to try out new things. In particular, I wanted to test out a load balanced architecture that will work within any VPS environment. Before I begin provisioning “real” servers and having companies bill me, I wanted to test that my ideal architecture works. I’m using the word “real” here to denote servers that will be public-facing and acting in a production-like capacity, as well as incurring billing charges. ...

When people have looked at my code, specifically my test code, one of the most common things they ask is why I test my getters and setters. They see this as a weird thing to do, but I tend to be a very paranoid defensive programmer, so I like to ensure that my getters and setters aren’t actually modifying anything. “That is paranoid, Scott” you proclaim, and try to enlighten me on all the code that doesn’t modify accessor methods. But I’ve been burned by this assumption often, and a simple and stupid unit test ensures that the code is adhering to my assumptions. It’s quick and painless. ...