PageTypesServiceTest.test05: assert allowedChildTypes membership, not struct iteration order

[alexskinner]

What

PageTypesServiceTest.test05 asserts the exact ordered string returned by getAllowedChildTypes():

super.assertEquals( "casestudy,blog,event,some_page_type,page,teammember", pageTypeBean.getAllowedChildTypes() );

That value isn't a meaningful ordering — it's the iteration order of a plain struct. The casestudy page type declares no allowedChildPageTypes, so it defaults to *, and PageTypesService._calculateManagedPageTypes() expands * to listSiteTreePageTypes().toList(), which is just for( id in registeredPageTypes ) over a default {} struct.

That iteration order is an engine implementation detail:

• On Lucee, a default {} is backed by a Java HashMap, iterating in hash-bucket order — the source of casestudy,blog,event,....
• Engines/configs whose default struct preserves insertion order (e.g. an ordered struct, or other CFML engines) return the same members in a different order.

So the test currently passes/fails purely on the host's default-struct ordering, even when the service is behaving correctly — the set of allowed child types is identical ({blog, casestudy, event, page, some_page_type, teammember}), only the order differs.

Change

Sort both sides before comparing, so the assertion checks membership rather than incidental order — consistent with test02 in the same file, which already does ids.sort( "textnocase" ):

super.assertEquals( ListSort( "casestudy,blog,event,some_page_type,page,teammember", "textnocase" )
                  , ListSort( pageTypeBean.getAllowedChildTypes(), "textnocase" ) );

The test still verifies that a * allowed-children type resolves to every site-tree page type; it's just decoupled from an unspecified struct iteration order.

How it surfaced

Running the Preside test suite on an alternative CFML engine whose default struct is insertion-ordered. test05 is the only order-coupled assertion of this kind — test02/test12/test13 already normalise order and pass on both.