Go track, Simple Linked List, Execute function in tests

Exercism
1

In the Go track, the Simple Linked List exercise appears to be tested in an ambiguous way.

The Execute() function in the tests seems to assume that the list pointer is modified in place within the student’s implementations of Push() and Pop(). However, for Reverse(), it expects a new list pointer to be returned. This inconsistency can be confusing.

Additionally, the exercise skeleton suggests the following signature for Push():

func (l *List) Push(element int) *List

but the returned value is not used in the tests.

It might be more consistent to adopt a uniform style for all student-implemented functions. For example:

func (l *List) Pop() (*List, int, error)

Currently, the test implementation can break otherwise valid solutions. In particular, this occurs in cases where elements are pushed into an empty list and the student’s Push() correctly returns a new pointer, but the test does not account for it.

2

It’s common for collections to have some methods that update the collection (eg pushing or popping) which other methods do not.

The exercise gives you starter code with the function signatures explicitly set for you. It’s expected you use those stubs without changing the signatures. Those stubs should make the expectations pretty clear.

Here are the stubs you start with:

func New(elements []int) *List { ... }
func (l *List) Size() int { ... }
func (l *List) Push(element int) { ... }
func (l *List) Pop() (int, error) { ... }
func (l *List) Peek() (int, error) { ... }
func (l *List) Array() []int { ... }
func (l *List) Reverse() *List { ... }

Where do you see that? The signatur, as given above, is func (l *List) Pop() (int, error)

If the student’s implementation does not follow the given/expected signatures, the tests will break. This is true regardless of what the signature looks like. This is why you’re given the expected signature. Students are supposed to implement the functions without modifying any signatures.

2 Likes
3

I’ve just rechecked the proposed function signatures using the online editor rather than my local setup. Indeed, Push() should not return a pointer to a new node.

At some point, I was struggling to understand why my solution wasn’t passing the tests and asked an LLM for help, without noticing that it had altered the function signature.

Apologies for opening this topic unnecessarily.

In the version provided in the online editor, everything does appear to be consistent.

1 Like
4

No worries. That’s what this forum is here for! To help people figure things out.

I’m glad to hear that. We try to ensure consistency, but we don’t always succeed! It’s users like you that help catch us when we slip up.

I would strongly caution against letting an LLM write code for you. The act of writing code is crucial if your goal is to improve your code-writing skills. LLMs can be great for explaining something to you or showing you an example of how to do something in code, but I’d caution against going any further and having it generate solution code. In fact, it could be helpful to explicitly tell it to avoid writing code that solves the exercise for you.

Good luck and have fun!

1 Like