Error when referencing a variable in the parameter of a query in the assert block

[dgosbell]

I get the error 'The variable named 'myVar' is not defined.' when running the following test. If I remove the @Myvar from inside the parameter in the assert and replace it with a hard coded value the test runs correctly.

I need to use a variables in the assert because our staging area is incrementally loaded during the day so I want to compare row counts based on the max date in our cube excluding any records that have been loaded since the cube was last processed.

  <test name="'Variable Test" uid="0001">
    <system-under-test>
      <resultSet>
        <query connectionString="@sql-edw-db">
          <parameter name="var">@myVar</parameter>
          select @var;
        </query>
      </resultSet>
    </system-under-test>
    <assert>
      <equalTo>
        <query connectionString="@sql-edw-db">
          <parameter name="var">@myVar</parameter>
          select @var;
        </query>
      </equalTo>
    </assert>
  </test>

Full stack dump from error:

Errors and Failures:
1) Test Error : NBi.NUnit.Runtime.TestSuite.INFR Compare WorkOrders fact to Ellipse WorkOrder Count
   System.AggregateException : One or more errors occurred.
  ----> NBi.Core.NBiException : The variable named 'myVar' is not defined.
   at System.Threading.Tasks.Task.FastWaitAll(Task[] tasks)
   at System.Threading.Tasks.Parallel.Invoke(ParallelOptions parallelOptions, Action[] actions)
   at NBi.NUnit.ResultSetComparison.BaseResultSetComparisonConstraint.ProcessParallel(IResultSetService actual)
   at NBi.NUnit.ResultSetComparison.BaseResultSetComparisonConstraint.Process(IResultSetService actual)
   at NBi.NUnit.ResultSetComparison.BaseResultSetComparisonConstraint.Matches(Object actual)
   at NUnit.Framework.Assert.That(Object actual, IResolveConstraint expression, String message, Object[] args)
   at NBi.NUnit.Runtime.TestSuite.AssertTestCase(Object systemUnderTest, Constraint constraint, String stackTrace)
   at NBi.NUnit.Runtime.TestSuite.ExecuteTestCases(TestXml test)
--NBiException
   at NBi.Core.Scalar.Resolver.GlobalVariableScalarResolver`1.Execute()
   at NBi.Core.Query.QueryParameter.GetValue()
   at NBi.Core.Query.Command.DbCommandFactory.Instantiate(IDbConnection connection, IQuery query, ITemplateEngine engine)
   at NBi.Core.Query.Command.DbCommandFactory.Instantiate(IClient client, IQuery query, ITemplateEngine engine)
   at NBi.Core.Query.Command.CommandProvider.Instantiate(IClient session, IQuery query)
   at NBi.Core.Query.EngineFactory`1.Instantiate(IQuery query)
   at NBi.Core.ResultSet.Resolver.QueryResultSetResolver.Load(IQuery query)
   at NBi.Core.ResultSet.Resolver.QueryResultSetResolver.Execute()
   at NBi.Core.ResultSet.ResultSetService.Execute()
   at NBi.NUnit.ResultSetComparison.BaseResultSetComparisonConstraint.<>c__DisplayClass21_0.<ProcessParallel>b__1()
   at System.Threading.Tasks.Task.Execute()

[Seddryck]

Your use-case is really aligned with our view on variables. They have been added exactly for this kind of use-cases.

Do you use one of the latest beta or an older version?
Have you got a variable definition at the top of your test-suite?

<variables>
    <variable name="myVar">
      <query-scalar>
        <![CDATA[select top(1) maxDate from [audit].[Load]]]>
      </query-scalar>
    </variable>
 </variables>

[Seddryck]

Oups, sorry I can reproduce the bug and will investigate it. The bug appears to be that variables are not sent to the assertion.

[Seddryck]

The fix should be available at https://ci.appveyor.com/project/Seddryck/nbi/builds/19953732 or with Nuget the version 1.19.0-beta0097

[dgosbell]

Thanks for the quick fix, the beta works for me.

Note: I had one test using system-under-test*execute*\query instead of system-under-test*resultSet*\query and it was throwing an "object not set to an instance of an object" error.

eg.

<system-under-test>
      <execute>
        <query>
       ...

instead of

<system-under-test>
      <resultSet>
        <query

Is this by design or should both structures work?

[Seddryck]

@dgosbell Thx for the confirmation.

NBi has evolved since the version 1.0 and one of the biggest challenge is that many things were not anticipated. This is leading to some ambiguity in the syntax when adding new features … and from times to times, I reach the point where the best thing to do is to fully change the syntax. On the other hand, I always try to maintain compatibility with previous syntaxes.

This page will give you more info. Feel free to comment the issue that is linked in this page if you think that some other stuffs should be changed in the syntax.

Nowadays, the best practice when testing a result-sets (equalTo/all-rows/...) is to use system-under-test/resultSet/... (where … can be query but has many other options). The other syntax (system-under-test/execution/query) is just maintained for compatibility purpose (and for tests such as syntacticallyCorrect and fasterThan).