Author Archives: Michael

Overview of combinatorial testing

In complex programs, choosing valid test cases often means choosing from many different possible combinations of inputs to find the correct cases. Doing this could take an unnecessarily long time, slowing down the development process, and possibly causing some important cases can be missed. In the article, “Combinatorial testing: What is it, how to perform, and tools”, author Shanika Wickramasinghe explains the details of combinatorial testing, and how it solves the aforementioned problem.

Combinatorial testing involves using multiple combinations of variables for testing, with the goal of this being to verify which/how many inputs of test data, with this information then being used to design future tests. Some of the benefits of combinatorial testing include a larger coverage of possible test cases than normal testing, since multiple inputs are used, reduces the cost and effort of the testing process through the fact that it’s a faster method of testing, and avoiding redundancy, as combinatorial testing ensures that the same cases aren’t tested multiple times.

To better understand how combinatorial testing works, lets take a look at the author’s example. Say we’re trying to test a username and password functionality, and we decide we’re using combinatorial testing for this. Instead of each test case only including one username OR one password, like what would happen if normal testing was being used, each test case includes 1 username and 1 password from a pool of multiple usernames and passwords. For example, let the tested usernames be User1, User2, User3 and let the tested passwords be PW1, PW2. Then, test case 1 could be testing User1 and PW1, then case 2 would test User2, PW1, then case 3 would test User3,PW1, and so on. By doing this, every case would be covered with only 6 test cases, with the same case never being covered twice.

Other types and ways of implementing combinatorial testing are available as well. For example, the example listed above would be an example of manual combinatorial testing, where cases are manually selected from the pools of parameters, where in automated combinatorial testing, software or scripts are used to automate this process and create many test cases automatically. This is especially beneficial if there are many possible inputs, and manually picking each case would be too time consuming.

From the blog CS@Worcester – My first blog by Michael and used with permission of the author. All other rights reserved by the author.

Recognizing the value of different types of unit tests

Unit testing is a very useful and secure way to stabilize the development process, but despite that, some developers forgo the testing process altogether. In Gergely Orosz’s blog entry, “The pyramid of unit testing”, he covers the relationship between the time it takes to notice the benefit of certain types of unit tests, and the experience of the coder designing the tests. For example, a coder with limited experience may look at a code body, see there are no obvious problem cases to be caught by unit testing, and forgo the process, while an experienced coder may see the same code and choose to design tests for it for reason that aren’t as obvious, and that are more based on experience and intuition.

Gergely details 5 different tiers of the Pyramid of Unit Testing Benefits, with the tiers lower on the pyramid listing benefits that can be noticed immediately, and tiers higher showing benefits that are only noticed in a later stage in development. The lowest tier are the benefits offered by tests designed to validate code changes. These tests are purely designed to validate recent changes, and make no attempt to catch future cases that might not be a problem now, showing an immediate benefit compared to not testing. The next tier up is the benefit of separating concerns in your code, which serves to somewhat force the coder to write clean code, since if a code is to be testable, that usually means that dependencies are declared upfront, leading the code to have an easier to follow structure. The next tier is the benefit of having an always up to date documentation. Well written tests can serve as useful documentation for code, and, unlike documentation of implementation code, these tests won’t get out of date. The second to last tier is avoiding regressions. If changes are made to a code body with no unit testing, than regression and conflicts are more likely to be introduced compared to a code body with tests. Designing tests helps avoid this by catching these regressions/conflicts before they become problems. The highest tier of the pyramid is using tests as a refactoring safety net. While testing is useful for validating small changes, it’s equally as useful for providing a stable environment for refactoring. When required to make large scale changes, a developer is more likely to be comfortable changing a code body with a large amount of coverage over many unit tests, rather than a code body with no means of catching problem cases.

From the blog My first blog by Michael and used with permission of the author. All other rights reserved by the author.

First CS-443 Blog

This is my first blog for CS-443. It will include posts related to software testing.

From the blog CS@Worcester – My first blog by Michael and used with permission of the author. All other rights reserved by the author.

Open source planning how it can be leveraged

https://increment.com/planning/open-source-planning/

From the blog CS@Worcester – My first blog by Michael and used with permission of the author. All other rights reserved by the author.

The important of code visibility and how to maintain it

From the blog CS@Worcester – My first blog by Michael and used with permission of the author. All other rights reserved by the author.

The role of individual contributors in the development process

From the blog CS@Worcester – My first blog by Michael and used with permission of the author. All other rights reserved by the author.

My first blog

This blog will document other podcasts/blogs that covered interesting computer science/software topics.

From the blog CS@Worcester – My first blog by Michael and used with permission of the author. All other rights reserved by the author.