2

I have written a class that implements some BLE scanning functionality. I have also written some test code that helped me to manually verify my scanner works as intended.

Now I want to somehow preserve that test code for future use. But I find myself stumped - how would I do this? I am currently using a unit test method, but that's really just because it was the easiest way to add some test cases that I can run on demand with a single mouse click. The actual test however isn't suitable for being committed as a unit test, because:

  • it depends on external factors to have a result (it needs one BLE device in range to see that the code actually does something)
  • I can't really assert that result (since the "result" depends on the devices in range of the computer that's running the test, it will be always different)
  • the execution time is a scan period of 40 seconds, not milliseconds

All this pretty strongly suggests "not a unit test", since it goes against any reasonable definition of what constitutes a unit test. But what else is there, actually? Apart from maybe creating a brand new C# project with a console application, is there any feature in the MS Test framework that I can use to provide future me and my colleagues with code they can "just run" to check if the scanner works?

(Note: I'd usually ask SO, but I guess this maybe fall under the category of "asking for tools", so I figured I'm better off asking here)

LWChris
  • 129

2 Answers2

2

A unit testing framework is not restricted to "unit tests." They are general purpose frameworks allowing you to write test code. More generally what you describe is a good fit for an integration test. Don't throw the code away. It helped you develop this. It can help you maintain it.

The challenge is setting up an environment where you can execute this test repeatedly. Consider adding instructions some place in the codebase telling people how to set up this integration test environment. Perhaps this is something your team does on an as-needed basis.

Alternately, bring this up with your team and management. Compile a list of the hardware and software requirements to run these integration tests. Communicate the benefits. You might be surprised and get support to stand up a dedicated integration test environment.

The last challenge is making an assertion. You mention that the results depend on the devices in range. Consider making tests specific to a certain device, or generalizing the assertion. For example, say you have two different brands of scanners that produce JPEG images. Depending on the specific codec, you could end up with different binary data. Certainly you could not do a pixel-by-pixel comparison, but you could ensure the image size is within some pre-defined range, and that there exists some standardized meta data in the image. Perhaps calculate the resolution and assert it is within some acceptable range.

I'm not sure what kind of "scanner" you are dealing with, but try to think of ways to assert the output that can be generalized to multiple scanners, types of scanners, or different manufacturers.

You have written valuable tests. Don't throw them away. There is nothing wrong with spinning them off into their own project, providing instructions on how to set up the environment, and then having developers run them as-needed. Communicate the benefits and requirements to the team. They might be interested, and you might be a trail blazer moving their process to include more automation. This is a good thing.

Greg Burghardt
  • 45,304
0

Standard unit testing frameworks like "MS Test" or "NUnit/JUnit/xUnit" are optimized for running fully automated tests. Sure, they can be used not only for real unit tests, but also for tests which require a longer execution time or some long-lasting I/O. But when a test requires user interaction, they will come to their limits.

Hence, I consider your idea of "creating a brand new C# project with a console application" as perfectly sensible. To make this code "future proof", I would consider to go a step further and think of a simple user interface for that application. The UI should

  • tell you (or the dev who runs it) the manual steps for preparation of the test (for example "switch BLE scanner on and press a key ...")

  • tell how to verify manually whether the test was successful or not (for example "verify the display of the scanner shows 42")

(I don't know if your scanner has something like a display with numbers, but I guess you get the idea.)

Maybe be a console UI is sufficient, or maybe you decide to implement a simple, lightweight GUI (which should not really be a huge effort with C#). Ultimately, this depends on how complex the test and the manual interaction are. But sometimes the most simple solution is to create a missing tool by oneself.

Doc Brown
  • 218,378