• State Not Answered
  • Replies 4 replies
  • Subscribers 7 subscribers
  • Views 2242 views
  • Users 0 members are here
Related Discussions
Home » Discussions » AI and Rules

We've started looking at using the saved test cases functionality and startR

Gavin Hume
Certified Senior Developer
We've started looking at using the saved test cases functionality and startRuleTestsApplications (and related) functions to run daily tests of all of our expression rules but am unsure how best to include tests for expressions that retrieve data from a database table. Given that the tests can either check that there was no error (of limited use), check that the output matches a given value or test that an assertion is true we're struggling to see how this can be made dynamic. In our current, process model based testing framework, we have used a Query Database node to directly query the database table to get both valid input parameters and expected output, before calling the expression rule with differing input parameters and then asserting the actual expression results matches the expected results. If we were trying to replicate this using the saved test cases we would have to be using another expression to return the expected result bu...

OriginalPostID-225576

OriginalPostID-225576

  Discussion posts and replies are publicly visible

  • 0
    Certified Senior Developer
    ...t this 'expected results' expression would probably end up looking identical to the expression that we were trying to test, which defeats the object.

    Has anyone considered the same issue and found a resolution (the only other option we are considering is a pre-processor step that would initialise the database tables with known data that could be used to test the expression rules and/or populate a set of expected results)?

    Any help would be greatly appreciated.
  • 0
    Appian Employee
    As you described, the issue with verifying the results of an external call (not only databases but web services or any other APIs) is that you can't verify the data or the result of queries using the data without already knowing what it is going to be. I dont think verifying external data is really within the scope of this kind of automated test cases. If you want to ensure that the queries are performing as expected beyond the fact that they are not throwing errors, then using a default/known dataset might be the simplest approach, but given that in practice you will most likely be trusting the database as the source of truth for the data, then it may be sufficient just to ensure that there are no errors thrown by the expressions.
  • 0
    Certified Senior Developer
    Thanks for the response Tom, it's much as I suspected. I suspect that, for simple queries we'll rely on testing that there are no errors and for more complex expressions we'll separate the query from any additional logic and inject the query results into that expression, in that way we can more thoroughly test the additional logic.
  • 0
    Appian Employee
    No worries. That sounds like a sensible approach to me

© 2024 Appian. All rights reserved.