This project is read-only.

Test availability of one or more members in a hierarchy or level.

System under test

If you're not familiar with the way to specify a test on members of a dimension, read first the article about Tests on dimension's members.

Assertion

One unique member

The assertion consists in a check that one of the members in a hierarchy (or level) has a given caption. To achieve this goal, we need to specify that we'll perform an assertion of type contain:
<test>
    <assert>
        <contain/>
    </assert>
</test>
Then we need to stipulate the caption to look for. We'll achieve this by filling the attribute caption with the analyzed caption (here MyMember).
<contain caption="MyMember"/>

Full sample: If we're checking that the hierarchy named "MyHierarchy" has effectively a member named "MyMember":
<test>
    <system-under-test>
        <members>
    	    <hierarchy caption="MyHierarchy" dimension="MyDimension" perspective="MyPerspective"
		connectionString="Provider=MSOLAP.4;Data Source=MyServer;Integrated Security=SSPI;Initial Catalog=MyCube;"/>
	</members> 
    </system-under-test>
    <assert>
        <contain caption="MyMember"/>
    </assert>
</test>

Several members

You can also check in a unique test that two or more members are part of a hierarchy (or level).
From a unit testing point of view you can argue that it’s probably not a good idea to ensure a correct granularity of the report. On the other hand, you can use this feature to be sure that a whole set of predefined value not coming from our main source (as N/A, Unknown, Not defined, (All)) are effectively available in your cube. Anyway, NBi support this feature.
Based on sample above, your system-under-test is not modified but in your assert you’ll need to define one xml element named item by member that you’ll check. If you're checking the availaibility of three members named My first member, My second member and My third member, you'll need to write following test:
    <assert>
        <contain>
            <item>My first member</item>
            <item>My second member </item>
            <item>My third member</item>
        </contain>
    </assert>
The test will only succeed if all the members defined in your assertion are effectively in the hierarchy (or level).

All members belong to a predefined list

Imagine that you’ve a hierarchy gender. You know that the only two choices are male and female, other values are not expected and should fail your test. You won't be able to assert the test with the assertions defined above.
First case, it could happen that you’ve only loaded men (or women). In this case, your assertion with members of hierarchy gender abou the fact this hierarchy effectively contains female will fail … but your data warehouse is correctly loaded! You probably want to check that members of this hierarchy are not different than male and female and not the male and female are available. The assertion subsetOf is there for this case.
With the assertion subsetOf, you can ensure that the members are not outside a predefined set of value, but you'll not ensure that all of them are available.
    <assert>
        <subsetOf>
            <item>Male</item>
            <item>Female</item>
        </subsetOf>
    </assert>
This test will only succeed if all the members of your hierarchy are value provided in the list of item. If you’ve any member of your hierarchy not included in the two members provided in your assertion, the test will fail. The test will not fail if your hierarchy contain only one of the the members provided in the assertion.

You know exactly all the members

In some case, you know exactly the content of your hierarchy or level. In this case, you’ll probably want to test that the whole hierarchy is correctly loaded in your cube. This can be achieved with the usage of the assertion equivalentTo. You'll need to provide a list of item with the corresponding to the list of members expected.
    <assert>
        <equivalentTo>
            <item>Male</item>
            <item>Female</item>
        </equivalentTo>
    </assert>
The test will only succeed if your hierarchy has exactly two members named Male and Female. If you’ve more or less or different items, this test will fail.
Note that this test is equivalent to two assertions contain (one for Male and another for Female) and one assertion subsetOf (for Male and Female). It’s just a matter of readability versus reporting and investigation facilities.

Dynamic list of members in your assertion

New in v1.3
Until now, we've learnt how to perform assertions against a static list of members. Since version 1.3, it's also possible to have a dynamic list of members retrieved from a query (Sql, Mdx or DAX).
This can be useful if you've a list of members stored in a relational database and that this list is in a constant evolution (customers, malls, ...). To achieve this, you'll need to provide a one-column-query in place of the list of item. This one-columnquery is just a standard query_ xml element where only the first column of the resultSet will be used by NBi. You can define this xml element as:
    <assert>
        <equivalentTo>
            <one-column-query>
                select displayName from Customer
	    </one-column-query>
        </equivalentTo>
    </assert>
The query will be executed and the first column of the resultSet will be used to build the list of expected members. Then, the assertion will perform exactly as previously defined for a static list of members.

Display the difference

New in 1.3
If your test has failed, NBi will provide you a list of missing and/or unexpected items according to the assertion performed
  • For equivalentTo: missing and unexpected items
  • For contain: missing items
  • For subsetOf: unexpected items
This list will be limited to 10 items maximum.

Last edited Oct 5, 2013 at 8:05 AM by Seddryck, version 3

Comments

No comments yet.