Add unit tests

[drakegens]

This is just a draft to begin a conversation. You can refer to the TimePickerTest.elm file. Curious as to your thoughts on what should be tested. Spoke with someone on the elm slack on whether or not it's ok to expose functions strictly for the sake of testing. He seemed to think that is ok, because you can't cause side effects/mutate anyways, as opposed to OO languages.

What do you think?

[stephenreddek]

@drakegens Thank you for working on this! This initial reason I always have for not exposing extra functions is that now you're tied into that specific implementation and data type. You cannot release an update that fixes a bug in one of those functions without making it a major version bump. In another way, it could also lead to someone relying on that particular function (unlikely in this particular case, but in the general case this can be true) and then you either remove it and they have to deal with it or you have to continue supporting it. The Internal.TimePicker style module is (I believe) one of the ways people fix this. You can expose the main module and not the Internal module but the tests can access the Internal module and any functions or types it exposes.