Development testing

Us web developers often need to redo the same actions over and over again. You know the story:

  • Make a code change.
  • Refresh the page.
  • Click on the right tab
  • Click several other things to get back to the modal you were working on

This happens over and over again until the feature or the bug fix is complete. Usually, I just program some scripts to help me redo these steps. Something like:
$(document).ready( function() {


With the occasional setTimeout thrown in, whenever you don’t have time to find a return event handler. It’s just temporary testing code, after-all. It works well enough for development. It’s a great way to get back to where you left off between a code change. And now, you can do the same with

Humanity needs a Software Update

We’ve all heard it before: two thirds of us in America are overweight or obese. And what’s the cause? Typically, we look around for the usual suspects: Processed foods have much higher caloric densities and everything that’s tasty is filled to the brim with sugar and fat. We’re too slothful, it’s said: not enough exercise. And, even if your a super health nut like me and only eat nuts, legumes and veggies, it’s still much easier to reach 2000 calories than say humans did millions of years ago. They didn’t have Chips, or fries or burgers or milkshakes. They didn’t have regular access to food, before agriculture was invented. We didn’t even begin to eat meat until a few hundred thousand years ago. You might say, we had seeds and nuts, but not the way we have em today. Today, we can waltz on down to Whole foods, pick up the Bin shovel and shovel a pound of seeds into the bag. Millions of years ago, you would have had to pick at a bush or ground, picking up each seed one by one, taking the entire afternoon to get a meaningful amount. Imagine collecting fruits: here’s 1 strawberry, and here’s another. ooops, that one was stepped on by a reindeer. Oh, there’s another one all the way over there. Imagining this scenario, I question the necessity of the 2000 calorie diet. Is it possible, that they ate substantially less? Perhaps spending the entire day hungry? After-all, the motivation for spending so much time finding food has to come from somewhere. Relentless hunger was what it took, to get us out of bed and foraging for food.

But, in the current age of excess, how does the other 1/3 of the population remain so trim. What’s their secret? All the epidemiological studies show, they generally eat the same garbage and get the same amount of non-exercise as the rest of us. How does that work?

The new york times wrote about a study where 24 twins were closely monitored for 120 days and overfed 84000 calories: The field of nutrition predicts that they should gain 24 lbs, according to the 3500 calorie rule. Some of the twins gained up to 29 lbs and some only gained 10 lbs! In each case, the twins always gained about the same amount of weight, thus the variation was not due to some auxiliary factors like differences in physical exertion or variations in food intake.

So, clearly, genetics is a factor and there’s something about those thinner twins that prevents them from gaining weight. Keep in mind that this reduce vulnerability to fat gain could work in tandem with reduced appetite to help keep weight steady effortlessly.

This is where the Set point comes in. The Set point theory says that our bodys attempt to maintain a certain weight. So, if your body wants to be 150 lbs, it’ll attempt to maintain that weight. If you overeat, it’ll reduce your appetite and increase your metabolism to get you back down to 150. Vice versa, if you go beneath that, it increases your appetite and reduces your metabolism to get you back to your set point. But, How can I be so sure that this is the case?

Think about this. 3500 calories surplus or deficit is what it typically takes to gain a pound or lose a pound. Over the course of 2 decades your body will ingest 14.6 million calories assuming you eat 2000 calories a day. So, if you over consume by even 5%, then you would be 200 lbs heavier and if you underconsume you’ll weigh 200 lbs less. Think about the neanderthals from millions of years ago. Did they walk around calculating their caloric intake? Did they even stop to weigh themselves to ensure they weighed the correct amount? Of course not. They ate and ate, exactly the amount their bodies told them too, or less based on whatever was available.

So, we’re not in charge of how much we eat. It’s up to our body to tell us precisely how much to eat. Ignoring hunger and eating less or eating lower density foods whilst compensating with higher nutritional value will definitely allow you to lose weight, but it’s not a solution. It’s only a matter of time before your body figures out you’ve lost weight and increases your hunger even more. Dieting is a hack. Excessive exercise is a hack. Eating less is a hack. These things are all hacks we’re doing against our bodies because our body’s software is programmed to attain and maintain a weight that’s too high.

It’s like having the thermostat in your house set to 90 degrees Fahrenheit, with the controls severed from the wall. It’s way too high, and we can’t lower the temperature on the device. So, we start hacking away. First you open the window and that lowers the temperature a few degrees. Of course, as soon as the temperature change is detected, the thermostat sends a signal to the heater to increase the flow of hot air, resulting in the temperature increasing back up to 90. So, if 1 window open isn’t enough, you start opening more and more windows. Meanwhile, your house is fighting you at every turn, piping ever more hot air, matching you move for move. Until finally, out of sheer desperation, you start doing things which you can’t possibly hope to maintain. You open up the garage door and the front door. This finally overwhelms your house’s ability to cope and the temperature begins to drop to a more comfortable level. But, it’s only a matter of time before your house gets robbed and you’re forced to close the garage door, the front door and the windows on the lower level, and your house resumes it’s temperature back at 90 degrees where it started from.

Now, this scenario is exactly what happens to nearly everyone that attempts to lose weight and keep it off. Most people are able to lose the weight but they almost always regain it. Check the NYT link above and read about the story of the woman who must keep her calorie count under 1000 per day, weighing every last thing that she eats, traveling with a scale.

So, why are our bodies so hell-bent on making us fat? The software that dictates our appetites, hunger and metabolism was written over an evolutionary period of millions of years, during a time when food was extremely scarce. Most of the time, you simply couldn’t find enough food to make you this fat. Even, amongst the healthiest foods, you find fairly calorically dense foods like seeds and nuts which us health nuts guzzle down by the tablespoon – this will reduce our appetite we’re told. But, this certainly wasn’t the case back in the day. Each walnut had to be opened by hand. You couldn’t just get a pound of walnuts from the grocery aisle. Foraging for and opening up nuts would take all day, as did obtaining other food. Modern day examples of these humans, in jungles show that they consume leaves all day long, grazing here and there. They couldn’t simply boil a pound of spinach.

The health conscious among you will argue that all we need to do is consume the foods that have the most satiety and hunger won’t be a problem anymore. High Fiber, high protein. It sounds great! This must work, right? Well, it assumes that foods high in relative satiety exist. I’m here to tell you, that they don’t. Sure, some foods are somewhat more filling than others. But, your stomach is extremely smart. It knows a lot more about nutrition and calorie counting than you or I do. When you really push the envelop and start eating really low density foods like spinach and other green vegetables in massive quantities, your body counts those calories quite precisely and adjusts your hunger accordingly. If you only eat 100 calories of cauliflower, guess what, your appetite is only decreased by roughly that amount.

So, what does it all mean? Our food conditions have changed drastically as well as the way we obtain our food and make our living. It’s no longer acceptable to be hungry all day long. Our bodies are running on outdated software written millions of years ago! Our appetite, hunger and metabolism is managed by algorithms developed under completely different circumstances. It’s time we updated our software and reprogrammed our metabolism, hunger and appetite. Everything else: (excessive exercise and dieting) is merely a hack. That’s not to say we shouldn’t eat healthy. But, at the very least, we need reduced appetite and hunger. The lucky ⅓ of humanity that already has the upgrade by chance through genetics (most likely), can vouch for the ease with which they maintain their weight. They don’t exercise excessively and they don’t go around hungry all day. They simply let their bodies handle the details, and that’s the way it should be.

Humanity has conquered nearly every inconvenience such as hot and cold weather. We have heated and AC’d buildings and cars. We have clothing to keep us warm. We have medicine and vaccines to counter sickness. It’s time we worked updated the most important software of all: the one that runs our bodies.

Implementing a Data Model

When developing, I often prefer to break code into MVC pattern, where every module is either a View, Controller or Model.  Keeping these separate allows you greater cohesion.

The model should only contain data manipulation without any reference to the DOM or DOM bindings.  Keep the interface to an absolute minimum.  And you shouldn’t be calling functions outside this module.  Model Modules should be completely independent of any outside running tasks.  If you require data from outside the function, you should pass it in via an argument. This prevents any dependencies on outside code: making the Data Module much easier to test. At this point, you can include the Data module in any other project or a testing application without much work. And, that’s how you know, you’ve done it right.

High Cohesion Programming: stopping bugs before they happen

As software engineers, we all want to prevent bugs, preferably before they happen. Wouldn’t it be great, if you could prevent bugs, just by the way you design and implement your code?

Encapsulation is a great start: restricting direct access to your code.  Here are some ways to achieve that:

  • Restrict parameter variables in your function calls
  • Don’t return a value unless you need to
  • Prefer local variables over class variables.
  • Prefer class variables over globals.
  • Don’t access or call anything thats global, unless you are in class designed to that*

That last point includes a lot of things we don’t normally consider global: for instance the DOM (in a javascript app), or the Database in a backend app, or Singletons, static functions of classes, etc.  A DOM or Database can be considered global because it can be accessed from anywhere, theoretically.  So, you want to constrain access to it and only use it in places that are specifically designed to that.  For instance, you access the DOM in your Rendering code.

With greater software design experience, you’ll find that you automatically start writing smaller function calls, and smaller classes that do fewer things: they do a few things really well, rather than lots of things not so well, that’s the essence of cohesion.  This also makes them easier to do unit testing, if you’re writing a Data Module.  And, if your writing a View component on the web, that’s hard to test with unit tests, you might give our regression testing tool a try.

Why do bugs happen?

Your application was running just fine several days and now all the sudden, there’s a bug.  Any code change or software update, could conceivably cause a bug.  There are countless steps a company will take to prevent bugs from occurring throughout the various jobs functions.  Let’s take a look at the various steps:
  1. Engineers take great pains to ensure that software design limits the number of dependencies between various points of the software.  For example, variables are made local, instead of global and variable use is constrained as much as possible to prevent it from affecting other parts of the code.
  2. Engineers have to retest key parts of the code.  This involves assessing risk and retesting any areas that may be affected by any code changes.  This requires thorough understanding of the code and any dependencies
  3. QA and testers will test the code for a week or two to do extensive testing and apply automated tests.  They’ll typically run some regression testing software to ensure no new bugs were introduce: like our regression testing suite:
  4. Sometimes a limited release to a subset of users is made.  After which, a smoke test is run in the live environment to ensure nothing serious is broken.
  5. A Wide release occurs, after which another smoke test is run.

In order for a bug to make it past every one of these phases, some oversight needed to occur.  Usually, it’s some combination of user inputs that has not been anticipated, combined with a certain browser, certain user state, cookie state, browser state, location or any one of a number of combinations.  Many of these factors can be mitigated with good software design principles, testing, feedback loops from customers, and a fresh pair of eyes!

How to not break your code

Any code change, no matter how small, can cause a bug and break your code.  With codebases growing ever larger and more complex, the risks increase more and more.  So, how do you prevent it?

There are several ways to check your code, to ensure you don’t break your code.  It all comes down to making sure you don’t change any objects, variables that shouldn’t change.  For the function your modifying, take a look at the following:

  • Check return value, is it being altered in any way?
  • Check input values, are they references, that might be changed in this function
  • Look for globals that could possibly be affected by your function.
  • If you’re developing on the web, you’ll need to check if your function affects any of the DOM as this is inherently global.

The above is just a short checklist, you’ll want to examine.  If there’s any doubt, you’ll want to test any associated functionality.

And, before you hit the commit button, make sure to rerun your regression tests.  For super easy, no work regression testing: Give  a try. – How we got here.

We’ve just gone live with our Automated Testing Platform.  It’s been a long road getting here with lots of trial and error.  As a software engineer, for many year, I have an inherent appreciation for testing software that’s easy to use.  In the past, I’ve developed snippets of code to automate testing.  These testing snippets did the job, but they were one time use only and difficult to reuse.  And, these snippets had limitations: everytime the page changes, the JS context is lost.

Some testing platforms let you write code to automate testing.  Frameworks like Jasmine allow you to write your own test cases.  Some even let you record test cases with user input.  But, none of these frameworks actually create the tests for you.  That’s why I set out to create a testing platform that not only automates testing but also automates the creation of the tests.