The team I’m on is currently writing code in TSQL to generate TSQL code that will be saved as scripts and later run. We’re having a little difficulty in separating our unit tests between testing the code generator parts and testing the actual code that they generate.
I’ve read through another similar question, but I was hoping to get some specific examples of what kind of unit test cases we might have.
As an example, let’s say that I have a bit of code that simply generates a DROP statement for a view, given the view schema and name. Do I just test that the generated code matches some expected outcome using string comparisons and then in a later integration or system test make sure that the drop actually drops the view if it exists, does nothing if the view doesn’t exist, or raises an error if the view is one that we are marking as not allowing a drop?
Thanks for any advice!
It is reasonable to test the code you want to generate first. Once you know this code works, you can chceck strings as you mentioned.