1. 21
  1.  

  2. 5
    1. 4

      While only a minor point in the article, I was intrigued by the reflection that the conversion from Ruby to Go was relatively easy because the test suite executes Hub’s executable as a user would, instead of calling individual functions.

      This has me thinking a few things:

      1. “Integration”-style testing, where you interact with a system as a user would, is strictly better than unit testing
      2. Often there is a cost to this style of testing, though, as it can be challenging to setup different states
      3. Maybe CLI’s are particularly well suited to this style of testing, since there’s usually only so many ways to interact with them (stdin, stdout, flags, etc)

      I wonder how Hub dealt with the CLI making network requests in tests, though?

      1. 6

        Akkartik’s trace testing provides a similar piece of non-language specific indirection.

        It always bothers me to some degree, that heavily depending on the programming language for you testing environment (like mock objects) provides great ergonomics for creating tests. However, they cement an implementation so deeply, I wonder if they create much more commitment than any author intended.

        1. 5

          I guess different people mean different things when they say ‘better’, but I’d agree in the vague sense that I would rather be comfortable with some integration tests, than with good ‘unit test’ coverage and no integration/end-to-end tests.

          Also, if your system wasn’t tested in the first place, integration testing is often a necessary step before you can start unit testing as it requires reorganizing and decoupling your code.

          1. 3

            Answering my own question: it looks like the tests use given blocks to specify a fake API and responses that the CLI hits.