The team I'm working with is currently writing code in TSQL to generate the TSQL code, which will be saved as scripts and then run. We experience little difficulty in dividing our unit tests between checking parts of the code generator and testing the actual code that they generate.
I read another similar question , but I was hoping to get some concrete examples of what unit test cases we might have.
As an example, suppose I have some code that simply generates a DROP statement for a view, given the schema and name of the view. I just verify that the generated code matches some expected result using string comparisons, and then in a later integration or system test, make sure that this drop actually reduces the view if it exists, does nothing if the view does not exist or causes an error, if the view is the one we mark as not allowing to refuse?
Thanks for any advice!
Tom h source
share