Composite fields were introduced in Microsoft Dynamics CRM 2013 to combine multiple fields into a single field on the form. It’s a nifty way to display multiple individual fields, which are concatenated into one. The most common application of composite fields is used with the out-of-the-box Full Name and Address fields (e.g. Full Name composite field has individual fields First Name and Last Name). Automating send keys into composite fields can present some interesting behaviours when using Selenium with Microsoft Dynamics CRM.
I simulated automating entering input values into a composite field using the Selenium WebDriver in Microsoft Dynamics CRM 2016. The composite field on the form needs to be clicked first before opening the fly-out menu containing the component individual fields. For example, the Full Name field needs to be clicked first i.e. automate click on element By.Id (“fullname”). This opens the fly-out menu allowing the WebDriver to access elements in the composite field. Initially, I entered values into composite fields for my first name then last name using the WebDriver. From a testing and user perspective, this order is also intuitive and logical based on how it is set up on the CRM form. I got into a bit of a dilemma when I enter values via send keys, as my values do not get sent to the fields using the Actions sequence with Actions.SendKeys().
I experimented with composite field behaviour (manual testing as opposed to automating) by simply clicking the Full Name field to activate the composite field fly-out menu. CRM sets the focus to the first available control (First Name) field. Then, I click outside the fly-out menu once without entering any values into the fields, and CRM sets the focus to the Last Name. I click outside the fly-out menu again, and CRM throws an error because the field Last Name is set to Business Required and there are no values. It appears that the composite field fly-out menu cannot be closed until field Last Name contains a value.
We can tackle this problem by using the default CRM browser behaviour to our advantage. I know from my manual testing that clicking the Full Name puts the focus into First Name. That means that the field First Name is already set to clicked which was initiated by CRM.
We can alter our usual Actions sequence of entering values into fields by removing the actions.Click() step. This way, our test scripts do not throw any exceptions and valid operations are executed as intended. My snippet of code below shows actions.Click() removed from where it is usually found in the Actions sequence of sending keys into a field.
Another obvious work around to this problem without removing the actions.Click() step is by using the normal Action sequence but changing the order in which field to enter the values. Swapping the order in which field to send keys allows the Actions sequence to execute properly. We can do this by sending values first to the Last Name field, then to the First Name field. Here is example code of the following using the usual Actions sequence (encapsulated within my SetFieldValue class). I can reuse the same Actions sequence via EnterText() method with the First Name field without omitting the actions.Click() line.
When automating tests in Microsoft Dynamics CRM using Selenium, it is important to recognise browser behaviours of CRM composite fields and required fields, and how it can force your test scripts to execute differently with unexpected results. By recognizing this, we can work around a fix to how we would automate send keys to composite field elements.