trust boundaries and testing
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.