feat[mal]: Map and Label Error and Validation Tests

[RODO94]

What does this PR do?

This PR follows work completed in: #3604

I am writing tests for the Error and Validation describe() as part of larger work to write tests for all of the test.todos().

My plan is to push up a PR for each describe() section so I can deal with feedback as I go and hopefully improve / fix any structure or logic issues.

For error checking at the Tab, I went with checking for the border-left styling as I couldn't see anything more specific to work from. From here I checked that this is removed when a new feature is added but is reapplied when you click "Continue" without adding new inputs.

The original test.todos there was one for Maximum number as an inverse to the minimum it() block I have written, but I didn't think there was a maximum for this component so I removed it.

[github-actions]

Removed vultr server and associated DNS entries

[RODO94]

new function for adding multiple features added here

[RODO94]

Added a function to call for when we want multiple features added to the map, thought it would be an easier spot in future if there was an explicit function for it.

It uses the existing function for adding one feature but wraps it in a forEach with a temp Array there to feed in all subsequent arrays.

[RODO94]

mockTreeSchema was used here to remove the Date fields from the input. This was causing issue when we were trying to test for error messages and all of them being emptyDOMElements. We thought it was better to remove this since, as an input, it has test coverage outside of this.

[RODO94]

Thought an explicit function for adding multiple features would help with the issue of how we mock the map in the tests. Lower the chance of the issues I had earlier... utils felt like the right place and tried to keep it simple.

[jessicamcinchak]

Looks like a great start on more test coverage - a few comments to address/clean up before merging please!

[jessicamcinchak]

nit: I think toBeInTheDocument() would be a stronger check for visibility here? Per a11y requirements, we have many error wrappers that are always in the DOM, and their visibility is toggled depending on component error state.

[jessicamcinchak]

@RODO94 re-reviewing now - if this suggested change worked as expected here, can you also please update all other similar instances of DOMElement checks as well? Otherwise I think these are quite flakey tests not actually testing visibility of error messages like we intend?

[RODO94]

@jessicamcinchak for this, would it be the case that for the Input fields in the <TabPanels> that the errors are always in the document but just don't have any text in them so toBeInTheDocument() would come back yes even if there's no error messages displaying?

Would something like this be more specific?

    errorMessages.forEach((message) => {
      expect(message).toHaveTextContent(/(Enter|Select)/);
    });
    
    || or ||
    
    errorMessages.forEach((message) => {
      expect(message.textContent).not.toEqual(undefined);
    });

[RODO94]

Example here of error element before "Continue" is clicked:

<p class="..." id="error-message-input-text-species" data-testid="error-message-input-text-species"></p>

[jessicamcinchak]

Looking through other error handling tests in other components now and realising checking DOM element is used elsewhere too, let's leave this as-is right now. Sorry for confusion.

There's still many outstanding to-do's here that are more valuable to move onto than get hung up on this.