In order to test each individual data portal, the portal is instantiated by the javascript test suite. This includes mocking up all the calls to the backend and ncWMS needed to get the portal running with its default dataset. So the test suite includes a fake ncWMS getCapabilities call for the default dataset on each portal as a massive multiline xml string. These are thousands of lines long, and have to be updated when new default data is added to a portal.
The results of the getCapabilities query don't vary much based on dataset; a lot of it is boilerplate or highly predictable - the same set of projections, a separate listing of each colour available for each variable available, etc.
It seems like it would be straightforward to write a reusable getCapabilities-mocking function that accepts the unique ID of the dataset, the names of each variable in the dataset, and the list of timestamps for that dataset, and uses them to generate the massive pile of xml. (You might need spatial extent too, or a couple other things.) This would make updating the test suite for an existing portal or writing the test suite for a new portal easier.
In order to test each individual data portal, the portal is instantiated by the javascript test suite. This includes mocking up all the calls to the backend and ncWMS needed to get the portal running with its default dataset. So the test suite includes a fake ncWMS
getCapabilitiescall for the default dataset on each portal as a massive multiline xml string. These are thousands of lines long, and have to be updated when new default data is added to a portal.The results of the
getCapabilitiesquery don't vary much based on dataset; a lot of it is boilerplate or highly predictable - the same set of projections, a separate listing of each colour available for each variable available, etc.It seems like it would be straightforward to write a reusable
getCapabilities-mocking function that accepts the unique ID of the dataset, the names of each variable in the dataset, and the list of timestamps for that dataset, and uses them to generate the massive pile of xml. (You might need spatial extent too, or a couple other things.) This would make updating the test suite for an existing portal or writing the test suite for a new portal easier.Pretty low priority, though.