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.