Test exited without ending

[linuxdropout]

All nested tests now exit without ending.

Tape version: ^4.9.1 (latest)

tape('example', ({ test }) => {
  test('nested', t => {
    t.end()
  })
})

This code will fail to run.

[Qard]

Yeah, it seems t.end() is now required, even when only creating nested tests.

tape('example', t => {
  t.test('nested', tt => {
    tt.end()
  })
  t.end()
})

[ljharb]

An explicit t.plan or t.end has always been supposed to be required, at every level - this bug was fixed in v4.10.

[orangejulius]

@ljharb even thought this is technically a bug fix, it seems that many people rely on this broken behavior.

As someone maintaining several repositories that now have tests failing due to this change, I'd like to request reverting the bugfix in the 4.x line, and releasing a 5.x with the bug fixed.

That will allow everyone using semver to upgrade on their own schedule

[Qard]

As someone working on a project with literally thousands of nested tests like this, I agree--a major release fix would be nice here...

[ljharb]

Yeah, this is a fair point.

Do you think that it would be a reasonable patch release to explicitly allow a test that only has nested tests to not require the outer end/plan? iow, the requirement would present itself the instant you had a top-level non-nested-test assertion.

My hope is that that way we wouldn't have to jump to v5, we'd keep the bugfix in v4.10, and we'd remove the friction you are experiencing.

[orangejulius]

Do you think that it would be a reasonable patch release to explicitly allow a test that only has nested tests to not require the outer end/plan?

That would work for our codebase as far as I know, and it sounds like a good middle ground.

Personally I would prefer keeping things simple with a revert to unblock progress (Greenkeeper is already getting confused about other package updates since our tests are failing).

That said, I appreciate the time it will take to fix this either way, so I'd be fine with either. Thanks for taking a look at it :)

[ljharb]

@orangejulius if I can't fix it in the next day or so, I'll plan to revert, but I always prefer rolling forward than rolling back, since you can pin to ~4.9 of tape in the meantime to unblock yourself :-)

[Qard]

I believe we do not mix nested tests with other assertions, so that seems like a reasonable approach to me. I can't really speak for what the expectations are for the rest of the community though.

[linuxdropout]

+1 on the 'test that has only nested tests and no other assertions'. Would fix our library with literally 1 million tests written like this.

[ljharb]

Ended up reverting; I'll reopen #222. Hopefully v4.10.1 fixes this.

[orangejulius]

4.10.1 works great for us. Thanks for taking the time to handle this!