TritonDataCenter / mdb_v8

postmortem debugging for Node.js and other V8-based programs
Mozilla Public License 2.0
240 stars 18 forks source link

test suite could use common mechanism for standalone tests #101

Closed davepacheco closed 6 years ago

davepacheco commented 6 years ago

Many of the standalone tests in the test suite follow a pattern where they construct some objects in memory (in a JavaScript program), run gcore on themselves, then load mdb_v8 on the core file and try to extract that state and verify that it looks like it should. This is nice because it's pretty self-contained, and it allows our body of test data to be generated for whatever Node version you run the program with.

The problem is that most of these test programs duplicate the same logic for doing most of this. This is especially annoying as we add tests that extract values from the core files and then use those values for subsequent dcmds.

This change adds a common mechanism for standalone tests to use after they've set up the in-memory objects they want to use. You invoke this mechanism to save a core file of the current program and open an MDB session with mdb_v8 loaded on the core file. The mechanism ensures that the module was loaded successfully, and it provides an interface for invoking individual dcmd pipelines and getting the output. At the end, it attaches another MDB session to MDB itself and runs ::findleaks to print out leaks. This is a first step towards #92 (automated memory leak checking via the test suite).

davepacheco commented 6 years ago

This change is coming in with #27, which adds a new battery of tests for arrays. This test uses the new mechanism. I also converted one other test to use the new mechanism. I have not yet converted the rest of the tests.

davepacheco commented 6 years ago

Also as part of this change, I've added a package.json file so that the test suite itself can use Node packages. However, care must be taken with this -- the way we use runtests_node may invoke the same set of tests without rebuilding, so we should not add binary add-ons to the test suite's packages.