As it stands, we don't run this test in automation anyway. It appears the intention is to be able to run it as a standalone executable, point it to a binary file containing sdp and manually verify the output. If we want to run it in automation, we should come up with a standard input and an expected output. Otherwise, we should see if we can build it as a standalone executable, or just remove it.

Byron, what do you think we should do with this one? Thanks!

I _think_ this doesn't use any XPCOM in any meaningful way, so we should be able to build it standalone. We could also build it as a gecko gtest but make its only test-case disabled.

Dan I created this binary for the purpose of fuzz testing our SDP parser (which is at least 10 times faster via this binary then going all the way through Firefox). And I would like to keep it around for that purpose (assuming the effort to keep it around is not too high). And yes Byron is right this should be converted into a standalone binary. I don't think it makes sense to keep this around if get converted into a gecko gtest.

There's a prototype of xul-gtestifying this in bug 1257713. It proposes adding an env var, SDP_FILE_PARSER_FILE, rather than passing the file in via command-line. Building standalone is probably not an option. I'll attach the colossal linking failure.

Try run here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=84bcb3822d417f37927f543aad32ee723c75c795

Comment on attachment 8810003 [details] Bug 1316886 - Port sdp_file_parser unit test to standalone binary; https://reviewboard.mozilla.org/r/92470/#review92538 LGTM. Thanks for solving it properly!

Pushed by dminor@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/09b5ba29c6db Port sdp_file_parser unit test to standalone binary; r=drno