Common attribute to disable SmartFolderNode and TestCaseNode

Ask general questions here.
mrt
Posts: 259
Joined: Mon Mar 16, 2020 11:31 am

Common attribute to disable SmartFolderNode and TestCaseNode

Post by mrt » Wed Jul 27, 2022 3:34 pm

Dear all,

i want to disable all following Smart folders and Test cases in the current Test container.

Currently I am looping though all children, which include everything (TestCaseNodes, SmartFolderNodes, Recordings, ...)

Code: Select all

        
TestCaseNode currentTestcase = (TestCaseNode)TestSuite.CurrentTestContainer;        	
TestModuleLeaf currentLeaf = (TestModuleLeaf)TestModuleLeaf.Current;
        	
var children = currentTestcase.Children;
        	
int i = children.IndexOf(currentLeaf) + 1;
        	
foreach (TestSuiteEntry child in children.Skip(i))
{
   if ((child.GetType() == typeof(TestCaseNode)) || child.GetType() == typeof(SmartFolderNode)))
  {
      child.Checked= false;
   }
}
where the issue occurs in the line

Code: Select all

child.Checked = false;
Because I can only loop over some generic "TestSuiteEntries" and they do not have a capability of the .Checked property, also there is no .Enabled property.

Without splitting into separate IFs and casting, is there any elegant way to "just disable this item, regardless if it is a test case or a smart folder)?

thanks!

User avatar
odklizec
Ranorex Guru
Ranorex Guru
Posts: 7470
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: Common attribute to disable SmartFolderNode and TestCaseNode

Post by odklizec » Thu Jul 28, 2022 7:14 am

Hi,

I see no problem with the code you are currently using. It's how I would do it too. But I'm not quite sure what you mean with this...
mrt wrote:
Wed Jul 27, 2022 3:34 pm

Because I can only loop over some generic "TestSuiteEntries" and they do not have a capability of the .Checked property, also there is no .Enabled property.
Could you please share more details about those "generic" TestSuiteEntries? If you mean things like recording/code modules, you can disable those with module.Enabled = false;
For example, I'm using something like this to disable modules in Teardown section:

Code: Select all

    //disable cur. TC teardown section 
    var curTestCase = (TestCaseNode)TestSuite.CurrentTestContainer; 
    foreach(TestModuleLeaf module in curTestCase.AllModules)  
    {  
        if (module.IsDescendantOfTearDownNode())
        {
            module.Enabled = false; //enable  to enable it  
        }
    } 
Pavel Kudrys
Ranorex explorer at Descartes Systems

Please add these details to your questions:
  • Ranorex Snapshot. Learn how to create one >here<
  • Ranorex xPath of problematic element(s)
  • Ranorex version
  • OS version
  • HW configuration

mrt
Posts: 259
Joined: Mon Mar 16, 2020 11:31 am

Re: Common attribute to disable SmartFolderNode and TestCaseNode

Post by mrt » Thu Jul 28, 2022 7:30 am

Hi,

hmm, yes sorry, it was too confusing.

My above example is not working, because it causes a compile error:
"TestSuiteEntry" contains no definition for "Checked" ...
What I meant:
SmartFolderNode and TestCaseNode are two different types, both have the "Checked" attribute.
TestSuiteEntry is the more generic version, so everything (Smart folder, Test case, Recording, Code module, ...) is a TestSuiteEntry.

The .Children includes everything, so if I want to loop over the .Children, I cannot use a specific type, but I need to use a generic type like var or TestSuiteEntry.
-> but, neither var nor TestSuiteEntry contain a definition for "Checked" or for "Enabled", which leads to a compile error then.

So I need to adjust this non-working example:

Code: Select all

foreach (TestSuiteEntry child in children.Skip(i))
{
  if ((child.GetType() == typeof(TestCaseNode)) || child.GetType() == typeof(SmartFolderNode)))
  {
    child.Checked = false;
  }
}
to something like this:

Code: Select all

foreach (TestSuiteEntry child in children.Skip(i))
{       		
  if (child.GetType() == typeof(TestCaseNode))
  {
    ((TestCaseNode)child).Checked = false;
  }
  else if (child.GetType() == typeof(SmartFolderNode))
  {
    ((SmartFolderNode)child).Checked = false;
  }
}

This works, but it just looks ugly to me and I wanted to know, if there is some more elegant solution (similar to the non-working example) rather than having if / else and the need to cast the TestSuiteEntry to a TestCaseNode or SmartFolderNode to access the .Checked attribute.

Hopefully this is now less confusing? ;)

thanks, BR mrt

User avatar
odklizec
Ranorex Guru
Ranorex Guru
Posts: 7470
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: Common attribute to disable SmartFolderNode and TestCaseNode

Post by odklizec » Thu Jul 28, 2022 8:03 am

Hi,

OK, I now understand. I'm afraid, I'm not aware of any more elegant way. They solution with IFs appears to be the only option?

The only thing I found is something called TestSuiteCheckableEntry, which exposes method SetCheckState(CheckState state). This looks like something worth to try? The problem is, that Ranorex refuses to convert TestSuiteEntry to TestSuiteCheckableEntry ;) Or I'm doing it wrong? Unfortunately, there is nothing about TestSuiteCheckableEntry in the Ranorex API guide.
Pavel Kudrys
Ranorex explorer at Descartes Systems

Please add these details to your questions:
  • Ranorex Snapshot. Learn how to create one >here<
  • Ranorex xPath of problematic element(s)
  • Ranorex version
  • OS version
  • HW configuration

mrt
Posts: 259
Joined: Mon Mar 16, 2020 11:31 am

Re: Common attribute to disable SmartFolderNode and TestCaseNode

Post by mrt » Thu Jul 28, 2022 8:42 am

Ok thanks, I wasn't aware of the TestSuiteCheckableEntry - most likely because there is no information in the Ranorex API / help.

Then I would like to stick to the if-else-cast-solution and avoid using the TestSuiteCheckableEntry,
because most likely questions will popup later when there is no help available. ;)

thanks anyway!

User avatar
doke
Posts: 112
Joined: Fri Mar 29, 2019 2:33 pm

Re: Common attribute to disable SmartFolderNode and TestCaseNode

Post by doke » Thu Jul 28, 2022 10:09 am

Just being curious...
Why would you do need this kind of code?

mrt
Posts: 259
Joined: Mon Mar 16, 2020 11:31 am

Re: Common attribute to disable SmartFolderNode and TestCaseNode

Post by mrt » Thu Jul 28, 2022 10:38 am

I have a data source assigned to the parent test case for looping through input fields of different type (text, date, dropdown, reference, ...).

Each of these types has a separate recording to input the data, so each is in a different sub test case with a condition of the type on it.

When running the suite, one test case is executed and all other show up as "Ignored" in the report because the condition does not match.
I do not like to pollute my report with loads of "Ignored" lines, so I disable the test case by code because this way they do not show up in the report.

User avatar
doke
Posts: 112
Joined: Fri Mar 29, 2019 2:33 pm

Re: Common attribute to disable SmartFolderNode and TestCaseNode

Post by doke » Thu Jul 28, 2022 12:14 pm

Hi Mrt,

So if I iunderstand correct :

maintestcase - dataconnector1
- Filltestdata - dataconnector2 (coupled to id of dataconnector1)

dataconnector2 has layout like this:
testcaseid fieldname fieldtype value
1 name string "John Doe"
1 birthdate date 1-1-2000
1 country dropdown France

and depending on the fieldtype you run a different recording

Regards,
Don

mrt
Posts: 259
Joined: Mon Mar 16, 2020 11:31 am

Re: Common attribute to disable SmartFolderNode and TestCaseNode

Post by mrt » Thu Jul 28, 2022 12:36 pm

Almost. ;)
I use a very similar approach to yours for some other test, where i fill and assign data source for child containers dynamically.

But in this suite i made something different:

Simplified example:

Code: Select all

Parent Test case - data connector 1 including the values, e.g. Name = "John Doe", Today = "2022/07/28"
  Main Test case - data connector 2 including the metadata , e.g. Name = "Text", Today = "Date"
    Sub Test case: If type is Text -> fill data
    Sub Test case: If type is Date -> fill data
So there is no coupling of IDs , but a second data source for the Metadata is used, which looks up the value in the first data source and then executes the sub test cases based on the type (and some other metadata details like groups and so on).

If I use an implementation like this, I am completely independent and can run the exact same testcases with just a different data source on a whole different AUT.

Main purpose here was to make tests reusable in different AUTs in different environments by just changing the data source and not touching the tests or their structure at all.