8th checking stack depth in tests

Programming 8th
1

@axtens, I had another thought.

Instead of expecting nothing on the stack at the start of a test (still a mystery why this is not true), at the start of a test we put some string on the stack, and then check that the nth item on the stack is that string.

test.8th might look like

"acronym.8th" f:include
needs exercism/test
with: test

9 tests

test-begin "ignoring punctuation and casing"
    "CMOS"
    ( "Complementary metal-oxide semiconductor" acronym )
    equal?
test-end

\ ...
  • test-begin adds a known string onto the stack
  • equal? calls 3 check-depth as currently
  • check-depth ensures:
    1. there are not fewer than the 3 items on the stack, and
    2. 3 pick equals the known marker string
  • test-end merely drops the known string so the stack is in the initial state.
\ we expect the stack value at n+1 to be "-- test start --"
: check-depth \ ... n -- ...
  dup>r
  depth n:< !if     \ we have less than n items on stack
    con:red con:onBlack
    "PANIC: expected stack depth to be " . r> . cr
    "Stack is:" . cr
    .s cr
    255 die
  then
  r@ pick test-marker @ s:= !if     \ (n+1)th item is not the marker
    con:red con:onBlack
    "PANIC: expected stack depth to be " . r> . cr
    "Stack is:" . cr
    .s cr
    255 die
  then
  rdrop
;
2

I rather think that that may be the issue with the current implementation. I should go back and read what the depth-check does currently, but what it should do is check for a stack that is not less than 3 items deep. Did I see some test run where it complained about a 4 item stack? That would suggest that the depth-check was complaining either about depth more than 3 or depth not equal to 3.

3

P.S. Most recent 8th distro submitted to @ErikSchierboom a few minutes ago

4

That sounds very sensible Glenn!

5

The current check:

  • It will check the stack size is exactly 3.
  • The stack needs to contain (top-down): the actual value, the expected value, and the test name.
  • If the student has left more than one value on the stack, then there’s no way to find the expected value or the test name. That’s why it’s a panic not a mere failure.

If there is gunk on the stack before the test starts, how are the tests to know?

6

They can’t know.

dup assumes 1 item on the stack. If there are two dup doesn’t care because its job is to duplicate the top item.

The test words assume 3 items on the stack. If there are more, the test words shouldn’t care because they’re only concerned with name of test, what the student’s code generates and what the “golden” value is. Less than 3 items is an error. Greater than 3 items isn’t an error.

HOWEVER, I can see why you’d want to throw an error on a stack greater than 3 items: these are unit tests, and run in a closed environment – the tests aren’t written for, nor expect to be, part of a larger body of code – so the tests can demand more stringent conditions regarding items on the stack.

So go ahead and scream when the stack isn’t exactly 3 items!

7

I disagree. The equals? test puts the test name and the expected value on the stack and the expectation is that the student’s code puts one additional value on the stack. If it’s more then we are no longer comparing against the expected value, and we are no longer printing the correct test name.

If we want to get people fluent in 8th, then they need to be very much aware of the contents of the stack.

8

Well, going back to dup, is greater than one item on the stack an error?

9

But I’ve already conceded to your assertion in my however, so further argybargy is moot