Best way to test dev server

[stramel]

As @FredKSchott mentioned in a previous PR comment, I'm spinning up a discussion around the best way to approach this.

I have looked into it a bit, just doing some basic preliminary research. It seems that the best way to handle the testing would be to have a mixture of unit and integration style tests.

• Test the util/helper functions that can and do cause issues. (ie. cross-platform path conversions)
• Test the request handler as a whole without spinning up the dev server. This ensures that our request handling is working correctly and doing what we expect.
• Test the server as a whole. This ensures that all the configurations with the server are working and that we are correctly handling requests cross-platform.

The last tests are slower, but we shouldn't need as many if the request handler is adequately tested.

A few other notes:

• A different discussion, but I have mentioned the idea of pulling the dev server out into a separate package. I'm curious if we should do that first then add tests or the reverse to ensure we don't break anything in the process.
• Once the tests are in place, we can add some additional tests to assert the output and perform some cleanup to the output that has been brought up in other issues. (snow pack build clears the terminal #588, Logging hyper verbose on CI/CD - possible looping build #587, Pika 484, Pika 490, Pika 488, Pika 458, Pika 417)

To approach this, I would like to:

• Get the testing setup for each style of test
• Add a basic test for each
• Start working on adding more in-depth coverage

Ideally, this will make the PRs a bit more manageable and allow anyone who wants to, to help out after the testing is setup.

/cc @drwpow

[FredKSchott]

I was just working on some code that really could benefit from some more thorough unit test coverage, so a strong +1 to the plan outlined above. My only recommendation would be to add a few good test examples of each type of test, before moving on to the next type. A good test runner for 1 test is very different from a good test runner for 10 tests, so I think we'll learn a lot in adding a few before moving on.

I'm also not convinced we'll be ready to pull out the dev server anytime soon (or if that's the right approach, vs. pulling out the installer) so +1 on getting tests working in this repo without having to block on that decision.