Is the code below worth unit testing? - delphi

Question

I'm new to unit testing. And I don't know whether it is worth to unit test the code below. Here's sample method written in Delphi:
function TCoreAudio.CreateAudioClient: IAudioClient;
var
MMDeviceEnumerator: IMMDeviceEnumerator;
MMDevice: IMMDevice;
MixFormat: PWaveFormatEx;
AudioClient: IAudioClient;
HR: HResult;
begin
Result := nil;
if CheckWin32Version(6, 0) then // The Core Audio APIs were introduced in Windows Vista.
begin
HR := GetInstance().CoCreateInstance(CLSID_MMDeviceEnumerator, nil, CLSCTX_ALL,
IMMDeviceEnumerator, MMDeviceEnumerator);
if Failed(HR) then
Exit;
HR := MMDeviceEnumerator.GetDefaultAudioEndpoint(eRender, eConsole, MMDevice);
if Failed(HR) then
Exit;
HR := MMDevice.Activate(IAudioClient, CLSCTX_ALL, nil, AudioClient);
if Failed(HR) then
Exit;
HR := AudioClient.GetMixFormat(MixFormat);
if Failed(HR) then
Exit;
HR := AudioClient.Initialize(AUDCLNT_SHAREMODE_SHARED, 0, 0, 0, MixFormat, nil);
CoTaskMemFree(MixFormat);
if Failed(HR) then
Exit;
Result := AudioClient;
end;
end;
Is that method worth unit testing? If it is, what parts of it need to be tested?
Thank You.

Answer 1

The problem you face is how to test it rather then whether it should be tested.
This is a wrapper to a number of COM calls which could fail for many different reasons. Those possible COM failure conditions are the most important aspects to test for this routine. But you can't easily provoke the COM routines to fail. In order to test these COM failure modes you'd need to use a mock and that's quite a leap from where you are.

Answer 2

Unit testing is usually a bottom-up approach. So you would start unit testing the classes that are used in your function. After having made sure that all these classes are covered by unit tests, you could create a unit test for your function CreateAudioClient. The unit test for this function is probably very easy, something like this:
AudioClient := CreateAudioClient;
CheckNotNil (AudioClient);
Note that you normally unit test the interface of a class and not the body of a function or procedure.
Hope that helps.
The question if it is worth it, depends on a number of factor:
How easy is it to build a unit test for it? How much effort would it be?
How important is this part? Depending on how critical this part is, the answer may be always "yes, it is definitely worth unit testing" - or not.
How likely is it to change? If you think this method might change somewhere in the future then adding a unit tests avoids introducing errors later.

Answer 3

When unit testing a class that acts as an interface between your application and a third party API (even a system API) you want to test that the class calls and responds to the API correctly. You can't do this without some way to sense what is being passed to the API and return an appropriate response.
In your case you are making a series of calls to obtain an IAudioClient. I'd say your doing too much. More than one conditional in a function is one conditional too many (I think I just confused myself with that one). I would break it into several functions that you can test individually.
function TCoreAudio.CreateAudioClient: IAudioClient;
var
MMDeviceEnumerator: IMMDeviceEnumerator;
MMDevice: IMMDevice;
MixFormat: PWaveFormatEx;
AudioClient: IAudioClient;
begin
Result := nil;
if IsVista then
try
MMDeviceEnumerator := GetMMDeviceEumerator;
MMDevice := GetMMDevice(MMDeviceEnumerator);
AudioClient := GetAudioClient(MMDevice);
MixFormat := GetMixFormat(AudioClient);
InitializeAudioClient(AudioClient, MixFormat);
Result := AudioClient;
except
//Handle exception
end;
end;
function TCoreAudio.IsVista: boolean;
begin
Result := CheckWin32Version(6, 0);
end;
function TCoreAudio.GetMMDeviceEnumerator: IMMDeviceEnumerator;
begin
HR := GetInstance().CoCreateInstance(CLSID_MMDeviceEnumerator, nil, CLSCTX_ALL,
IMMDeviceEnumerator, Result);
if Failed(HR) then
raise Exception.Create('Failed to create device enumerator');
end;
function TCoreAudio.GetMMDevice(ADeviceEnumerator: IMMDeviceEnumerator): IMMDevice;
begin
HR := MMDeviceEnumerator.GetDefaultAudioEndpoint(eRender, eConsole, Result);
if Failed(HR) then
raise Exception.Create('Failed to retrieve device');
end;
function TCoreAudio.GetAudioClient(ADevice: IMMDevice): IAudioClient;
begin
HR := MMDevice.Activate(IAudioClient, CLSCTX_ALL, nil, Result);
if Failed(HR) then
raise Exception.Create('Failed to retrieve audio client');
end;
function TCoreAudio.GetMixFormat(AAudioClient: IAudioClient): PWaveFormatEx
begin
HR := AudioClient.GetMixFormat(Result);
if Failed(HR) then
raise Exception.Create('Failed to retrieve mix format');
end;
procedure TCoreAudio.InitializeAudioClient(AAudioClient: IAudioClient, AMixFormat: PWaveFormatEx);
begin
HR := AudioClient.Initialize(AUDCLNT_SHAREMODE_SHARED, 0, 0, 0, AMixFormat, nil);
CoTaskMemFree(MixFormat);
if Failed(HR) then
raise Exception.Create('Audio client failed to initialize');
end;
Now you can provide a mock/fake/stub to each function, ensuring the API is being called with appropriate arguments and forcing failure conditions to make sure your production code is handling them properly.
You don't need to ask if production code should be tested. The answer is always yes. (warning:shameless self-promotion) I wrote about this recently on my blog. Sometimes even the most innocuous of all statements, the assignment statement, doesn't work as expected.
Actually now that its broken down its starting to look like a new creational class just itching to break out.

Answer 4

it really depends on how often you believe changes will be made to this method... if you already have some tests for it's unit, then yes do it, otherwise it's really up to you, but I'm not sure it's a good idea to test only this method from the whole unit, because it calls other methods from other units.
Bottom line, it's really up to you how you choose to do it, best way is to add testing to whole project, otherwise I can't really see any value in "partial testing".