If the submitter changes the actual list while iterating through its elements, the existing tests won’t catch that. Example of a String() method that changes the underlying list:
func (l *List) String() string {
var listString string
for l.head != nil {
listString += fmt.Sprintf("%d ", l.head.value)
l.head = l.head.next
}
return listString
}
The function that just traverses the list in the exercise is the Array function. Are you suggesting that the test for the Array function should check if the list is not changed?
I saw you made a PR related to this where you call Array() twice and expect the result of the second call to be equal to the slice passed when building the list.
I’m a bit on the fence on accepting this test. Not only because calling Array twice doesn’t actually test if Array changes the list, and because tests in Exercism doesn’t need to be exhaustive, and this seems to be an edge case we can probably ignore.
Do you know of a solution for Array that would be more or less obvious to write without thinking to much that changes the original list? I’ll reconsider my opinion if such solution exists.