Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have a .c file that basically manages its own little database of people. There are add, remove, edit and search functions among some others. It has a static array which it uses to store the data.

What is a good way to go about unit testing a file like this? Because the array is static I can't put in my own data.

Should I employ some trickery and make a function that passes out a pointer to the array that gets compiled out in the production version? Should I just test the functions as is and make the data they way I want it via a series of adds and removes? What is the best way to test a file like this?

share|improve this question
add comment

4 Answers

up vote 3 down vote accepted

The best thing you can do is to refactor the code to make it more testable. Not only does this yield immediate benefits in testablity, it has long-term benefits like improved code readability.

If for some reason you can't refactor this code, you add some test-specific code that improves testablity. Namely, something that lets you set the content of the array. You can use #define in C to filter this code out of non-test mode execution.

share|improve this answer
    
How would you suggest going about this? One could rewrite the functions to take a pointer to an array along with the original arguments, but then then the array needs to be exposed to outside functions to pass in. Or the array could simply be exposed. Or there could be some variety of init function that took as input the array to be used for the data, so that it would be possible to pass it arrays in various states... None of the seems to, at first glance have benefits beyond increasing the test-ability. Are they helping in ways I don't see or is there another option I am not thinking of? –  Justin May 15 '12 at 4:09
    
@Justin It really depends on your specific code base. If you have a function that lets you specify the content of the array, you can code in expected values in the array and use your add, remove, edit methods to modify the original values. Then you need a way to examining the array contents. You need to be careful to only allow these functions in testing, to maintain your code encapsulation. –  Oleksi May 15 '12 at 4:16
3  
If you can add, remove, edit and search - how is this not already testable? Test away. –  Cwan May 15 '12 at 10:40
add comment

If you have a public interface for manipulating and querying the data, use it to verify that the behavior is as expected. It's only better not to access the static array directly; the static array is an implementation detail and manipulating it directly will only make it harder to refactor the module in the future.

What might be a problem is if the module internally interacts with the filesystem for e.g. loading and storing data without being explicitly told so; i.e. there is no public load/save API. That's hopefully out of scope for you, because that requires some more work to get testable.

share|improve this answer
add comment

you can refactor you code like this

old code

   static MyType[] myArray = ...
   void oldFuncThatUsesStaticArray(Type param1, Type param2, Type param3, ...)
   {
      // ... do the processing by accessing global static myArray  
   }

new code

   static MyType[] myArray = ...
   void oldFuncThatUsesStaticArray(Type param1, Type param2, Type param3, ...)
   {
      newFuncWithArrayParameter(param1, param2, param3, ..., myArray);
   }

   void newFuncWithArrayParameter(Type param1, Type param2, ..., MyType[] myArray)
   {
      // ... do the processing by accessing the parameter myArray
      // ... that hides global static myStaticArray  
   }

for the testing you call newFuncWithArrayParameter() while your app is still using oldFuncThatUsesStaticArray()

Note this is pseudo-syntax as i am not a c-developper

share|improve this answer
add comment

As Joel said in Things You Should Never Do, you should never rewrite the code. You can write your test codes to call the add, remove, edit and search functions in this file which verify the correctness of the functions and the static array. If the test codes can judge the testing result automatically, you have the base to refactor the code. Every programmer wants to change the original codes to their own, but the key element lies in whether the original codes are stable or not. Otherwise you will just do the useless work.

share|improve this answer
    
Never is a big word. It does of course depend on how big the code is, and how much you would need to rewrite. If the code is small & bad, then by all means rewrite it from scratch. For larger, complex programs I agree that rewriting is a bad idea. –  user29079 May 16 '12 at 20:44
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.