views:

33

answers:

2

I am porting over some C++ assembly to VB that performs demodulation of various waveforms. I decided to go the unit test route instead of building a test app to get a feel for how testing is performed. The original demodulation code accepts an array that is the waveform along with some other arguments. How should one go about performing a test on something that has an array as an argument? Is it acceptable to generate fake data in a file and read it in at the beginning of the test?

On a side note - The original C++ code was written because we were performing math that we couldn't do in VB6 so we had to cross boundaries between C++ and VB6 and arrays were used. Is there a "better" way of handling large amounts of data in the .NET world that us VB6 programmers may not yet be privy to? Or if we aren't crossing that managed/un-managed boundary, should we be representing our data as objects instead?

Thanks all!

+1  A: 

Depends on how big the test arrays are. If they are not so big, I would prefer keeping them in the code - this way unit tests are self containing, without dependencies to external resources.

However, if the array is huge, it can be stored in a fake data file. Alternatively, if generation is not very complicated or time consuming, it could even be generated on the fly.

Even if you decide to refactor your API, I recommend to write the unit tests first for the current API. Once you have the tests, you can refactor more safely.

Péter Török
A: 

The first thing is to get rid of the arrays. You said in your question the only reason for arrays was for an interface to c++. Now your code is vb.net so clean up that interface. You might originally start with a something that wraps the array: class WaveForm {}. Hide the representational details.

Gutzofter