tarantool / go-tarantool / 25367568580 / 1
75%
master: 76%

LAST BUILD BRANCH: bigbes/gh-238-request-value-receivers
DEFAULT BRANCH: master
Ran
Files 19
Run time 1s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 75.266% (-0.2%) from 75.435%
25367568580.1

Pull #586

github

bigbes 
tests: prevent leaked tarantool and panic on bad start

Two related issues from #147 made test failures painful to diagnose:

1. When a test panicked, the spawned tarantool process was left
   running and kept its TCP port bound, so the next run failed with
   "address already in use" instead of the original test failure.

2. The defer/require ordering used in many tests was

       inst, err := test_helpers.StartTarantool(opts)
       defer test_helpers.StopTarantoolWithCleanup(inst)
       require.NoError(t, err)

   When StartTarantool returned a nil instance on error (the connect
   failure path returns nil after stopping the half-started process),
   the deferred cleanup ran on a nil pointer and panicked, hiding the
   real "Unable to start Tarantool" failure under a nil-deref stack.

Fix the first by setting Pdeathsig=SIGTERM on the tarantool command
on Linux via a new test_helpers.commandKillOnExit helper, with a
no-op fallback for other platforms (darwin has no Pdeathsig
equivalent — see the comment in cmd_other.go).

Fix the second by reordering every offending test site to assert
StartTarantool succeeded before deferring the cleanup. This is the
standard Go idiom and avoids growing a nil-guard inside the helper
that would mask further StartTarantool bugs.

Part of #147.
Pull Request #586: tests: prevent leaked tarantool and panic on bad start

3113 of 4136 relevant lines covered (75.27%)

10018.03 hits per line

Source Files on job 25367568580.1