IDM has an 'ID Provider driver which generates unique IDs per one of a number of policies. It would be really nice if Validator had this option, perhaps as a connection option. The setup should be really simple for it to do. Accept an IP/DNS, port, policy ID, client ID (perhaps optional/random), and then store the retrieved ID in a variable for use later. The reason this would be nice is to allow testing of multiple ...more »
It seems like most "Assert ... Results Contains" tests support retries. The HTTP connector tests do not. That feature should be available across all assertion tests.
Store passwords in a way that:
Ties the serialized value to the local Validator install
Allows tests to be imported with "clear text passwords" that are then stored securely.
Separates the password storage from the test definitions.
Perhaps reuse the "named password" features in IDM to implement the storage?
Put the Description of the test into the results tab. Looking at many very similar tests having the Description can make it so much easier.
And on a failed test, particularly one where values are compared. Show the value found. This is a standard feature of Junit where it shows both expected and actual values. Right now you show only expected value in the report.
Since many workflows are started automatically, it would be helpful In the UserApp connector if there was a way to get a list of workflow approvals pending for a particular user. This would allow us to know if the workflow was automatically started correctly.
Add a parameter to select a specific test in a suite file to run from command line.
I would like to create a suite with two tests, one basic for Swift verification and one for mor thorough tests.
Then I want to run these from command line.
It will be a maintenence problem to put these tests in diffrent suite files, since they will be based on the same set of templates.
We would like to put quite a lot of information in variables. It would simplify the overview if there was a built in namespace/grouping functionality. This would make it possible to introduce folding for each namespace/Group.
In the UI one could unfold only the section one is interested in.
To make validator tests more maintainable, it would be nice if one could reference other sets of variables/connectors or templates from a suite.
It will be easier to 'divide and conquer' testing if some common parts could be reused instead of having to copy/paste between suites.
Enabling a variable value to point to a connection, would allow easier development of modularity in templates and tests. The use case I have involves multiple eDirectory connectors with in a single system. A variable change to the connection name in a common template would allow a single template to be used for similar tests in each of the different eDirectory trees. Currently, the only way to achieve this easy reuse ...more »
IDM Validator 1.2 UserApplication Connector User Interface, etc. After setting up a UserApp connection and getting PRDs tested for the first time a few things would really help make this much simpler. First, allow browsing to the PRD. Designer doesn't provide the DN anywhere convenient, and even finding the CN can be a challenge. Since browsing the vault is already an option (for a different type of connection, of ...more »
The current validator runs a dos batch file that starts the Java Process and all the magic happens. The issue I have is it is easy to accidentally close the DOS box and than you have a mess with the interface open and no process to preform the operations. There has been a user who has provided this as an add on yet each revision has broken it and I am not aware if you can still obtain this for the most recent versions. ...more »
When you copy a function to a complimentary fuinction, for example, Copy an Add Object and change it to a Delete Object, the corresponding fields should be maintained. The DN from the add object should become the DN of the delete object (right now it puts the class name in when you do that).
When your action makes a change to object attributes, the prior values should be preserved, so that a new action could "undo" the change. You could either stack the prior values, or allow the undo to reference a specific change.
The Analyzer product seems to not be used much even though everybody that has access to the Advanced Edition has a license for it. It would be great to tie the existing connections that validator has and allow analyzer to take that connection information and connect to the various connections. Or it would be great to tie in new functionality into validator that would perform the Analyzer functionality. Compare values ...more »
If test coverage for default driver config can be developed, consider a mode of storing the Validator config in an eDir object (DirXML-Resource class, with DirXML-ContentType=mime/Validator-test-suite) so that when you import drivers from Vault in Validator, you also get a default test suite. Would allow developers to ship drivers with test suites included.