jeudi 9 juillet 2020

Is throwing an AVE a good simulation of pulling out the plug

I want to test my code's resilience in the face of having been spontaneously terminated.

Is adding Test triggers to throw an AccessViolationException a good simulation of that?


I have some code that processes messages from a ServiceBus Queue. It runs on Azure Functions, which means every now and then it'll just get spontaneously turned off whilst executing. grumble grumble in-practice unreliable infrastructure grumble grumble.

The code is reading messages properly such that the messages will still be in the queue if that happens. Woot!

But that doesn't mean I'm home free, because it still might cause problems if a half-processed entity can't be re-processed.

So I'm tasked with making that code fully Idempotent, even in the face of being terminated mid-execution. (i.e. Lots of Transactions and expected state checking)

I want to be able to test this resilience, but that involves being able to entirely stop execution of the code, including any of the error handling code.

My plan is to add Test Triggers into suitable areas of the codebase, which trigger AccessViolationExceptions (which don't get caught by a normal try ... catch), and have a dedicated AVE-catching block in my test.


Question:

Would this (throwing an AVE) be a good proxy for "having the power cord pulled out when it hits this line"?

Or are there differences that I haven't considered?

I can confirm that there are no AVE-catching blocks in the prod code :D

Aucun commentaire:

Enregistrer un commentaire