Since testing a complete web application, by using the browser for instance, has become nearly impossible, developers have come up with alternatives. Best practice is to use unit tests, testing only a small part of each application at a time. But, this means you may have to change the way you write your code in order for it to have a testable structure. Let’s talk about how you can get this done.
Why not just use automated testing?
This sounds like one big circle. So, how can the code be written in a testable structure?
The first step is to organize your code. Application components should be separated by area and not all mixed together. By separating the behaviors, you are closer to the well-structured organization. Presentation, data retrieval, and event handling are a few examples of areas that should be separated into individual groups.
To go one step further, each area should then be broken down even further into subcategories. Because each distinct area will not actually have to know what the others’ functionality is or if it even exists, you will be well on your way to finding out what went wrong when the time comes.
Many times in the testing phase, something will go wrong and the traditional integrated testing makes it pretty hard to identify what that something was when everything is jumbled and mixed together.
Gluing the pieces together
The end result should be small, condensed pockets of functionality. If you were writing an essay, each paragraph would be only on one topic. The same goes here. They should each be operated independently, and the glue is the application code.
When web pages are separated into smaller modules, like we have been discussing, it creates automatic isolation of the code. Isolation helps unit testing by removing bad interactions between systems, and components run better when there is less setup. Small code means less complexity and easier testing.
Consider interactions with the server. When a bunch of different things are happening in only a short space of code, it’s going to be difficult to unit test. Writing your own unit tests will take time, but it’ll be less time than not writing them and ending up with problems later. Catching bugs and potential headaches quickly will make it time well spent.
Cleanliness is next to godliness
If you want to be able to test well, you also have to keep a clean house. Clean and clearly written code bases are the foundation of a good test. If the tester does not understand why each unit is being tested and how it fits into the big picture, they cannot create optimal future tests. Code authors should document parameters, properties, and methods using standardized methods. Authors should include comments if needed and always use standard terms, instead of abbreviations that could be later misinterpreted.
This sounds like too much work, are you sure there is not a shortcut?
No, there are no shortcuts, per se. There are MVC frameworks that have built-in support and help with the unit testing of applications. But, if you are not writing your code in the absolute best style for testing, you are going to run into some problems by depending on a framework such as Angular JS or Backbone. You need to know you are choosing the right tool for whatever job you are looking to do and understand how the tool is going to help you. There are some great unit testing tools available like Jasmine, Mocha, and QUnit to make life easier.
Separate your code by breaking down the logic behind each code and creating smaller modules to work with. It’s a good idea to write small tests as you write your code. But considering that you will be constantly changing your functions, staying organized means you will still be able to write your tests later on and have them work. Keep your code clean, clear, and easily understood by the person doing the testing, and everyone stays happy.