23 Oct 2015 @ 12:25 AM 

It should not come as any sort of surprise that verifying that software works properly relies quite heavily on testing. While in an academic environment, it can be possible to prove that an algorithm will always work in a certain way, it is much more difficult to prove the same assertions with a piece of code implementing that algorithm; even more so when we consider the possibility of user interaction, which adds a arbitrary variable to the equation.

When dealing with large or complicated projects, testing needs to be done in layers. In addition to testing by using the same interface as the user and ensuring it all acts as expected, it is also reasonable to add code-level tests. These tests will run functions and methods or use classes within the program(s) and verify that they work as intended. This can be used quite fruitfully in combination with normal testing to identify regressions easier.

Some languages, such as D, include built-in, compiler/language-level support for Unit Tests. In D you can define a Unit Test within the block that you want to test, usually it is tied to a Class instance, as shown in the documentation examples.

The D Programming Language Logo

The D Programming Language Logo, Which I’ve inserted here for no particularly salient reason.

Different languages, platforms, and frameworks will tend to do tests differently. Most languages and platforms don’t have the sort of Unit Test functionality we see in D, but as the industry has matured, and particularly with design concepts like test-driven development being pushed to the forefront, most development platforms have either had Unit Test functionality added to them by third parties, or had it added as an integral component.

Unit Test Projects

In Visual Studio, Unit Test Projects can be added to a solution. Test Classes and Test Methods are added to that project, and they can reference your other projects in order to test them. This is a particularly good approach for testing libraries, such as BASeParser. BASeParser is a relatively straightforward recursive descent Expression parser/evaluator, which was one of my first C# projects, which I had based off of a VB6 library of the same function and name. This is actually a very straightforward thing to test; we can have a test method merely have a set of expressions and the expected result, and verify that evaluating that expression provides the expected value:

By running a test- or integrating a test into your build process- you can have the new version of the program verified to provide correct results. If you rewrite a critical part of the program to improve performance, you don’t want to make the results wrong- having these sorts of checks and balances in place can let you know right away if a commit you made has just caused regressions, or broken expected behaviour. You can run these tests directly from the IDE, which is a very useful feature. A small marker appears next to the Method header, and you can click it to get test options- run the tests, run all tests in a class, debug tests, etc. The Debug capability is particularly valuable, as it can help you step into and determine why something is not failing. For example, the test shown above helped me to trace down a problem with operator precedence and function evaluation. And these are very basic tests, as well.

I’m also working on Unit Test related features and capabilities, which includes integration into Jenkins, but for obvious reasons I can’t be going and showing you that, now can I? 😉

Posted By: BC_Programming
Last Edit: 23 Oct 2015 @ 12:25 AM

EmailPermalinkComments Off on Unit Testing Basics
Tags
 21 Sep 2015 @ 10:56 PM 

Unit Testing. Books have been written about it. Many, many books. About Unit testing; about Testing methodologies, about Unit Testing approaches, about Unit Test Frameworks, etc. I won’t attempt to duplicate that work here, as I haven’t the expertise to approach the subject to anywhere near that depth. But I felt like writing about it. Perhaps because I’m writing Unit Test code.

Currently what I am doing is writing Unit tests, as mentioned. These are written using C# (since they are testing C#, so it makes sense), and they make use of the built-in Visual Studio/NET Unit Testing features.

In my mind there are some important ‘cornerstones’ of Unit Tests which make them useful. Again, I’m no expert with Unit tests but this is simply what I’ve reasoned as important through my reading and interpretations on the subject so far.

Coverage

making sure Tests engage as much of your codebase as possible applies to any type of testing of that code, and Unit Tests are no exception to that rule. It is important to make sure that Unit Tests execute as much of the code being tested as possible, and- as with any test- should make efforts to cover corner cases as well.

Maintainability

When it comes to large software projects, one of the more difficult things to do is encourage the updating and creation of new Unit Tests to make sure that Coverage remains high. With looming deadlines, required quick fixes, and frequent “emergency fixes” It is entirely possible for any Unit testing code designed to test this to quickly get out of date. This can cause working code to fail a Unit test, or Failing code to pass a Unit Test, because of changing requirements or redesigns or because code simply isn’t being tested at all.

Automation

While this in part fits into the Maintainability aspect of it, this pertains more to automation of build processes and the like. In particular, with a Continuous Integration product such as Jenkins or TeamCity, it is possible to cause any changes to Source Control to result in a Build Process and could even deploy the software, automatically, into a testing environment. In addition, Such a Continuous Integration product could also run Unit Tests on the source code or resulting executables and verify operation, causing the build to be marked a failure if tests fail, which can be used as a jumping off point to investigate what recent changes caused the problem. This can encourage maintenance (if a code change causes a failure then either that code is wrong or the unit test is wrong and needs to be updated) and is certainly valuable for trying to find defects sooner, rather than later, to try to minimize damage in terms of Customer Data and particularly in terms of Customer Trust (and company politics, I suppose)

I repeat once more than I am no Unit Test magician. I haven’t even created a completely working Unit Test Framework that follows these principles yet, but I’m in the process of creating one. There are a number of Books about Unit tests- and many books that cover Software Development Processes will include sections or numerous mentions about Unit Test methodologies- which will likely be from much more qualified individuals then myself. I just wanted to write something and couldn’t write as much about Velociraptors as I originally thought.

Posted By: BC_Programming
Last Edit: 21 Sep 2015 @ 10:56 PM

EmailPermalinkComments Off on Unit Testing
Tags

 Last 50 Posts
 Back
Change Theme...
  • Users » 47469
  • Posts/Pages » 390
  • Comments » 105

PP



    No Child Pages.

Windows optimization tips



    No Child Pages.

Soft. Picks



    No Child Pages.

VS Fixes



    No Child Pages.

PC Build 1: “FASTLORD”



    No Child Pages.