adding generate_unit_test_template macro

[bruno-szdl]

resolves #250

Problem

When creating a unit test, it is a bit painful to go through all the input and expected models, get the model name and column names, and write all the YML code. Especially if the model has a lot of inputs.

Solution

A macro to generate a unit test YML skeleton. A macro example is in the issue description.

@dave-connors-3 provided some feedback

• We are thinking you could add a helper function that returns the entire resource dictionary, which you could then key into for info like resource.resource_type and resource.package_name etc. This might make your life a lot easier!
  • I added Dave's helper function and I'm using it to retrieve some configs, instead of splitting the unique id. It is undoubtedly better this way. I didn't feel the need to modify his helper function at all.
• We should test quoting + case sensitivity rules for all uses of column names.
  • Not sure how to do it. Could you help me here?
• I think we could do away with the boilerplate description! while it's best practice it's not required and I fear how many boilerplate descriptions may accidentally make their way into production code!
  • Makes sense! I removed it.
• We'd love to see a newline after each column for maximal readability + ease of adding column values!
  • Can we discuss this point? In my opinion, when you need to add several input rows, I'd rather keep one line per row, so you can see it as a table, with the values of each column straight below each other. If there's a new line for each column, it is harder to visualize it as a table.
• do we need the {{ print('\n') }} ? should we just add those directly to the string / avoid accidentally erasing the newlines with whitespace control characters?
  • Agreed it is a bad practice. Adjusted.

--

Also, I added a relation exists check, so we only try to retrieve the current model's columns if the model exists in the DW.

--

I'd love to hear your thoughts about the modifications and how we can improve the macro.

Usage examples

dbt run-operation generate_unit_test_template --args 'model_name: order_items'
dbt run-operation generate_unit_test_template --args '{model_name: model_incremental}'
dbt run-operation generate_unit_test_template --args '{ model_name: order_items, inline_columns: true}'
dbt run-operation generate_unit_test_template --args '{ model_name: order_items, inline_columns: false}'

Checklist

• This code is associated with an issue which has been triaged and accepted for development.
• I have read the contributing guide and understand what's expected of me
• I have run this code in development and it appears to resolve the stated issue
• This PR includes tests, or tests are not required/relevant for this PR
• I have updated the README.md (if applicable)

[dbeatty10]

We'd love to see a newline after each column for maximal readability + ease of adding column values!

• Can we discuss this point? In my opinion, when you need to add several input rows, I'd rather keep one line per row, so you can see it as a table, with the values of each column straight below each other. If there's a new line for each column, it is harder to visualize it as a table.

Thanks for opening this PR @bruno-szdl! We can totally discuss this piece.

It seems like we have 4 options here:

1. All column names on one line.
2. One line per column name.
3. Extra parameter that allows users to choose between 1 and 2 (defaulting to 1).
4. Extra parameter that allows users to choose between 1 and 2 (defaulting to 2).

Option 2) is easier for me when adding values (because my eyes can see line breaks easier than scanning for : horizontally.

But option 1) is easier to read as a table once the values have been input (assuming the text for the values is all similar width).

Here's an example of manually adding strategic whitespace to make at most readable as a table:

So it seems like it depends what we're trying to optimize for here.

What do you think the pros/cons are for each of those (4) options?

[bruno-szdl]

Hey @dbeatty10, now I get it. The 'table view' in the docs is because it was manually adjusted to align the column names.

Personally, I still prefer the inline way, but I like the approach of giving the dev the option via parameter. And I don't mind making the multiline option the default one. So I like the option 4)

I have modified the code to allow those two options. The new parameter name is inline_columns, but I'm not good at choosing names, so feel free to alter it xD

Now I'm wondering if we should add a parameter to give the option of csv and sql formats.

[dbeatty10]

This is looking awesome @bruno-szdl 🤩 (and sorry for the delay in getting back to you!)

The get_resource_from_unique_id macro was defined twice, so I removed one of those within 809991d in order to pass CI.

A couple things that we'll want to do before merging:

• Add test cases similar to those found in the integration_tests/tests directory (see here for one example)
• Add documentation + example(s) within README.md on how to use this maco (see here for one example).

I addressed these comments

[dbeatty10]

@bruno-szdl I took care of the following:

• Add test cases similar to those found in the integration_tests/tests directory (see here for one example)
• Add documentation + example(s) within README.md on how to use this maco (see here for one example).

So ready to rock!

(It's not passing Circle CI for Snowflake only due to a stale password. So merging without that one.)

[bruno-szdl]

@dbeatty10 Hey Doug, thanks a lot for taking care of those. I was swamped these last few days. Glad to contribute to codegen with your help!!

[dbeatty10]

You're very welcome @bruno-szdl ! Awesome to get to collaborate with you on this ❤️