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
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
Then we need to stipulate the caption to look for. We'll achieve this by filling the attribute
with the analyzed caption (here MyMember).
If we're checking that the hierarchy named "MyHierarchy" has effectively a member named "MyMember":
<hierarchy caption="MyHierarchy" dimension="MyDimension" perspective="MyPerspective"
connectionString="Provider=MSOLAP.4;Data Source=MyServer;Integrated Security=SSPI;Initial Catalog=MyCube;"/>
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
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:
<item>My first member</item>
<item>My second member </item>
<item>My third member</item>
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
, 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
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
and not the male
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.
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
. You'll need to provide a list of item
with the corresponding to the list of members expected.
The test will only succeed if your hierarchy has exactly two members named Male
. 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
in place of the list of item
. This one-column
query 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:
select displayName from Customer
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.