Automatic smoke tests for the tools

[goldshtn]

We have reasonably solid tests for libbcc and the Python modules, but nothing at all that exercises the tools. Seeing as a lot of people use the tools from bcc, and nothing else, we should provide at least some very basic smoke tests that would ensure tools don't break in a completely obvious way. Some of the more obvious ways we've seen recently:

• Importing a class that doesn't exist (lingered for weeks unnoticed, fixed, then accidentally reverted (!), then fixed again)
• Internal kernel functions/enums/structs changing and breaking tools on newer kernels
• Infrequently used features in a tool broken by other changes in the tool

For a lot of tools, just running timeout -s KILL 1s the_tool and checking that we don't get an error status is sufficient for a basic smoke test. Testing the actual output would of course be better, but we have to start somewhere.

Thoughts? @brendangregg @4ast @drzaeus77

[drzaeus77]

Absolutely! How about adding a --dry-run flag to the most popular tools (with others to follow) which only compiles the bpf program with the common defaults and then does a cleanup + exit?

[brendangregg]

Yes to such smoke tests.

I'd test:

• timeout -s INT 5s the_tool # simulate Ctrl-C
• the_tool 5 # or -d 5, or however the tool implements a duration (if it does, many do)

No tool should spit out a Python exception trace in these conditions.

[brendangregg]

Oh, and we could add --dry-run to tools that initialized everything and then exited. I would not put --dry-run in the man page, and I'd hide it from the USAGE message if possible.