How do i run dbt tags and selector together something like below.
dbt test --select +selector:every_3h,+tag:CT0
This command is not giving me the required output.
In a best effort to be direct, I believe you are simply using selector syntax wrong here.
A selector is by definition a shortcut to a set of critieria.
It should be all inclusive of the things you want to accomplish.
Maybe try something like:
selectors.yml
selectors:
- name: every_3h
definition:
method: tag
value: CT0
value: every_3h
parents: true
Then, when you run the testing command, you simply indicate the selector:
dbt test --selector every_3h
Hope that helps.
Related
I have a generic test and need it to be always saved under a particular name for the given table it is running on, e.g. on table report_revenue the generated generic test name will always be diff_check_report_revenue. Right now the default dbt naming behavior for generic tests is kinda messy (it sets the test name based on the test config, which is a great idea for most cases, but unfortunately not for my particular one).
According to the docs it looks like the [alias]https://docs.getdbt.com/reference/resource-configs/alias is exactly what I need. However, I also need to set the name dynamically based on the table that is tested. I know it can be set in the yml config by setting the field alias, but I hope there might be a more elegant solution.
When I try the following:
{{
config({
"severity": 'warn',
"tags": ["diff_check"],
"alias": 'diff_check_' + {{ model | replace("XXXXXXX") | trim }}
})
}}
It just doesn't work and dbt completely ignores the alias property. model is the relation on which the test is running. It's probably just my own wrong syntax, but I'm stuck and humbly asking for advice. Thanks a lot in advance!
The docs are super confusing on test config, since they group together generic tests and singular tests, and the behavior is different.
You can use a config() block inside the definition for a generic test to configure it, and some keys (e.g., severity) work fine, but alias is not one of them.
I think alias is meant for singular tests only. To give generic tests a unique identifier (only possible since v1.1), you are supposed to use the name property (not config). Docs. Does this make sense? No. Does it make it easy for you to do what you want to do? Also no.
I'll point out that the default naming convention for a generic test includes the name of the test followed by the name of the model, but assuming that isn't good enough, your only option will be to add a name property to every test, where you define the test in the properties (fka schema.yml) file. And it looks like the name property doesn't jinja-template its value (so you can't use jinja to populate the test name). So you'll have to do a lot of this:
models:
- name: my_model
tests:
- diff_check:
name: diff_check_my_model
You could fork dbt-core. The relevant code is here.
How to append Configuration variable in Feature name or in Scenario name. For Instance need to provide Info in reports based on environment run.
I saw there is an option available to add the Examples variable in Scenario outline name. on a similar note, do we have option to append Environment variable in Feature name?
Yes, in 1.0 onwards - if a variable exists in scope, it will be substituted in the Scenario name using the JS string interpolation syntax.
For example if your karate-config.js is like this:
function fn() {
return { test: 'foo' };
}
It means that the variable test will be available when the Scenario is processed. If not, note that the test will fail.
So if your feature is like this:
Feature:
Scenario: ${test}
* print test
You will see this in the report:
So it is up to you how you set up variables in the configuration init.
So I currently have an automation pack that I have created using Selenium/Specflow.
I wanted to know whether it is possible to have multiple BeforeTestRun hooks?
I've already tried: [BeforeTestRun("example1")] but I receive an error stating BeforeTestRunAttribute does not contain a constructor that takes 1 arguments
I tried the following but that also failed:
[BeforeTestRun]
[Scope(Tag = "example1")]
And referenced the above in the .feature file like this:
#example1
Scenario: This is an example
Given...
When...
Then...
Is there a way to implement this correctly such that in one .feature file I can have two scenarios that can use different [BeforeTestRun]?
If you cannot use [BeforeScenario] like suggested, you can try to manually check for tags using if statements. To get the current tags and compare them to the ones you need, try this:
var tags = ScenarioContext.ScenarioInfo.Tags;
if (tags.Any(x => x.Equals("MyTag")))
{
DoWork();
}
More info here: https://stackoverflow.com/a/42417623/9742876
I am using the free (non-PRO) SoapUI 5.0 and I have a list of properties in a Test Suite.
I then have a number of Test Steps, each one having the same name as a Test Suite property.
I'm trying to write Groovy script in a Test Step property to retrieve the value of the Test Suite property with the same name.
For example:
Test Suite has a property colour_red with the value 12345.
Within the Test Suite is a Test Case, with a Test Step also called colour_red.
Within the colour_red Test Step is a property "info".
I'm trying to get the property value for "info" to be the Test Suite
property colour_red value of 12345.
What I have so far in the "info" property value:
${=new GroovyShell().evaluate(testRunner.testCase.testSuite.project.getPropertyValue(context.getCurrentStep().getLabel()))}
I'm not sure if I need the new GroovyShell().evaluate bit, but without that it still doesn't work. I cannot tell exactly what is being picked up but it is not the value of the Test Suite property with the same name.
From what I can see the script should retrieve the current Test Step name (colour_red) and then look for a property called that in the Test Suite.
My reason for doing this is that I have data in the Test Suite property values which needs to be shared between numerous Test Cases (all with many Test Steps).
Without the PRO version I am struggling but I think with Groovy there should be a way to do this.
Any help appreciated, thanks.
I think researching property expansion will help you.
http://www.soapui.org/Scripting-Properties/property-expansion.html
To get you going...
You can easily reference property values using these dynamic references:
Put a reference like ${#TestSuite#colour_red} as the property value of "info".
Now the info property value is dynamicaly set to whatever the TestSuite's colour_red property value is.
I think this does what you want:
def myStep = context.currentStep.name
def myValue = context.expand( '${#Project#' + myStep + '}' )
testRunner.testCase.setPropertyValue("info", myValue)
I made it a little more verbose than it needs to be. I do not think that -Pro will help you, unless I misunderstood what you need.
I'm a Selenium n00b... it's clear how easy it is to run a test and verify a particular response, but how can I take a value from one response and use it in the next test?
an example might be a contact creation form...
type in name/email and click submit
response arrives with new ContactID
grab the ContactID that was returned and put it into "get" textbox and click "submit"
response arrives with contact details
verfy the name/email match the first set
how might I go about doing this in Selenium?
And now something completely different:
Now I understand when you say "test", you mean a single assertion within one test case. So you want to use a value returned from a request as input for another request in the same test case.
Assuming you use selenium ide: To do this, use one of the "store..." commands in selenium ide and store the value into a variable. The contactID can be found using a matching selector with the storeText command. For example:
command: storeText
target: selector for element containing contactId
value: contactId
Then, use variable substitution and the type command to insert that text somewhere else.
command: type
target: selector for target input box
value: ${contactId}
Hope this helps :)
(This answer is still correct I think if you interpret "test" as "test case". For another, totally different answer see below.)
You don't do this. Each test should be independent from all other tests. For your second test, just repeat the steps in the first test. This way, you can reproduce test success and failures in a reliable way.
If you have many tests which all start from a certain application state which requires many steps to reach, just write a private helper method to reach that state.
The alternative: All steps you describe can be put into a single test. There is no reason not to have several asserts in one test.