Unit testing is the method by which individual units of source code are tested to determine if they are working as expected. In simplest terms, a unit is the smallest testable part of an application. A unit could be an entire module, but is more commonly an individual function or procedure. In object-oriented programing a unit is often an entire interface, such as a class, but it could be an individual method as well. Unit tests are created by developers or occasionally by testers during the development process.
Ideally, each unit test is independent from the others: substitutes like method stubs, mock objects, fakes and test-harnesses can be used to assist testing a module in isolation.
Unit testing is the cornerstone of many development methodologies, with early error detection relying on an automated unit testing framework created by the development group or by using a third-party application.
Why Automated Testing?
The human factor is a primary reason for augmenting your test strategy with automation. The difference between “testing” and “checking” is an important distinction – human intelligence is best used for in-depth testing that requires exploration and analysis, whereas automation is best used to for confirmation that the paths through the system work (i.e., checking). By incorporating automated strategies into your testing plan, you can use the tools to check that the basic functions are working while your testers focus on exploring more complex interactions.
Used properly and early, automated testing provides quick insight into whether an application is working properly. With that feedback, developers can make corrections to their code early in the cycle, speeding up the iterative improvements that make quality products.
Does Code Coverage Matter?
It’s important to keep code coverage metrics in perspective. Code coverage refers to the amount of code covered by (and tested by) unit tests. While the metric is interesting, it seems that it led to a lack of focus about what is most important about unit tests. You can certainly hit all your code with some basic unit tests that go stale over time and don’t provide you with much value. OR… you can put some intelligence behind the code you do cover and how you test it, which then focuses this metric on achieving code coverage in those areas of the code that make your application most vulnerable.
No matter how you use this metric, it is important to know your code coverage when you are building your automation framework.
Why Use an Isolator?
Unit tests are not integration tests. The purpose of a unit test is to confirm that a particular portion of the code is functioning as expected. There are a number of strategies you can employ to achieve this goal, including using an isolation framework that allows you to break dependencies on other areas of code outside of the unit being tested.
Tools like Typemock Isolator provide a mocking framework that allows you to mock dependencies anywhere, even in legacy code.
“Typemock Isolator brings the ability to mock dependencies, and thus to build true unit tests”, according to Gil Zilberfeld, Typemock Product Manager, “Furthermore, Typemock Isolator’s SmartRunner makes the entire unit testing experience easier, which makes unit testing implementation in the organization a way of life.”
How can a Profiling Tool Help Unit Testing?
Creating unit tests that confirm a module is working is really only half the story. Unit tests can tell you more than just a thumbs up/thumbs down on a particular area of code – they can also be very useful for providing performance metrics that can pinpoint bottlenecks and problem areas early in the development cycle. Running a profiler lets you dive down into various levels of the code to get distinct measurements during the unit test execution.
Using a tool like AQTime by SmartBear in conjunction with Typemock Isolator lets you take those unit tests and get specific performance information while you are running your unit tests. AQTime measures elapsed time, traces memory leaks, monitors resource usage and determines if the code was executed. The profiling process treats the test as a project.
Adding AQTime protocols to Typemock’s robust unit testing features give the developer a powerful unit testing toolset for code development. According to Zilberfeld: “The ability to profile real, isolated unit tests (as opposed to whole-system tests) shortens the investigation time by AQtime. In addition, using Typemock Isolator to mock dependencies, users can focus their analysis, without noise interference caused by dependencies, for example, third-party libraries.”