trust boundaries and testing

Published 03-01-2007 11:13 AM | jokiz

our current project which involves a client .NET windows application which emits data to an excel workbook to render different views of the data.  data are written on hidden worksheets which functions as my datasource for the views and graphs being rendered by my vba macros.

the excel workbook is my main task and from day one, i had this assumption that the client app is writing correct data to my excel workbook.  we're currently undergoing a series of test cycles and i'm beginning to doubt if having that assumption was correct in the first place.

i was not successful in convincing my teammate to write automated tests for the client application and as such a bug in writing data to my workbook results in failing assertions on my macros.  i'm just using debug.asserts which causes the macro to break in debug mode.  it could have been more helpful if there is a debug.assert(condition, message) feature which launches a messagebox like in .NET.

a number of issues had already been filed as part of my component only for me to find out that it's just the data being written which is at fault.  ideally, in my opinion, tests for the correct data should be part of the client's windows app client testing and tests on my part will just be the rendering of proper data.

Filed under:

Comments

# Comgen said on March 1, 2007 2:44 AM:

I don't know if im getting this right.

>> tests for the correct data should be part of the client's testing

Yes this is correct. The client's (end users of your app/component) should be the one doing the initial checking for the inputs and output. Here at the bank we have sign off sheets. This is a proof that the data and info that our app is producing are correct.

This is sheet is signed both by the Heads/Users/Developers after a Parallel/Mac Test.

Or else if the developers will be the one cheking it. They'll be paying hours of hours using "DEVELOPERS RATE" for checking the inputs and outputs. =)

Pero Ganun talaga minsan ang users reklamo agad pag mali ang output pag chineck natin hehehhe inputs pala nila ang problem.

# jokiz said on March 1, 2007 8:31 AM:

hi comgen,

i was referring to the "client" as the client application developed in .NET

# cruizer said on March 1, 2007 5:11 PM:

hi jokiz, your experience here is another argument for the importance of testing stuff in isolation. in your case, an error in another module (the one generating the file) cascaded into your module. it's perfectly valid to expect, in your case, error handling on your excel workbook stuff if it's a user that will feed data to it. but since it's a machine, it is expected that it should be giving you correct data.

# jokiz said on March 1, 2007 6:50 PM:

thanks for confirming that cruizer.  as a result of this, tester often encounter breaking in my assertions or even invalid castings which are taking my time to debug on which was the cause.  i think it will be better that i include a somewhat data cleansing utility or test that i could run on the newly written workbook, just to tell if client is behaving as expected.  well, that's just to easily tell if it's the client app's fault.

# Comgen said on March 4, 2007 5:08 PM:

Hehehehe mali nga ang kuha ko =P