Testing Refactoring

Tasks

• Make go test ./... work successfully
• Decouple packages and wire them all from cmd/engine
• Mock out a rethinkDB package for testing
• Rename all tests that are internal to <file_name>_internal_test.go
• Move any black box tests to <file_name>_test.go

Explanations

Testing Methodology

• Begin more black box testing. Currently we are testing internal to the
  package. This is ok when needed, but should be more of the exception and not
  the rule. For instance, if you are writing a test for the rpc package, the
  package name should be rpc_test. Also, to identify where internal testing
  does happen, naming conventions like rpc_internal_test.go can be used, and
  rpc_test.go as inherently known to be a black box test.
• Mocking out external dependencies. Currently many tests are relying on
  rethinkDB. This will become problematic as we scale the project. The sooner
  we can mock out these calls the better. I suspect this is actually a smaller
  problem than it might seem specifically because we are tightly coupled in
  several packages. Decoupling the packages will remove a lot of those
  dependencies without additional refactoring.
• Parallel tests. Many tests can't be run in parallel. Additionally, many
  packages can't be run in parallel for testing. We should be able to run go test ./... at any time and have successful outcomes as an entire project.

Decoupling

• I noticed in several areas we are creating tightly coupled package. Example from the worker package:

func NewSendCardWorker(e *graph.Graph, f *flags.Flags, s *store.Store) SendCardWorker

This should be something like:

func NewSendCardWorker(e *graph.Graph, f *flags.Flags, Store) SendCardWorker

where Store is an interface defined withing the worker package. This will
allow us to test the entire worker package without actually relying on a
store being present. We will create full level integration tests in another
package that will consume the actual store, as well as the store actually
consuming a live instance of rethinkDB.

rethinkDB dependency

As stated above, I think we'll need to create the proper mocks sooner than
later to enable rapid development. We can then create full level integration
testing as well to ensure that end to end testing is still working. These
end-to-end tests can likely run with a continuous build server, and not require
us to spend time locally testing it.

Summary

Our goal is to make back end development as rapid and painless as possible, but
ensure that we don't regress. The above steps should allow us to get much
closer to that goal (but more work will still be needed of course as we
continue to grow the code base).

Hola! @cgilson has created a ZenHub account for the october93 organization. ZenHub is the only project management tool integrated natively in GitHub – created specifically for fast-moving, software-driven teams.

How do I use ZenHub?

To get set up with ZenHub, all you have to do is download the browser extension and log in with your GitHub account. Once you do, you’ll get access to ZenHub’s complete feature-set immediately.

What can ZenHub do?

ZenHub adds a series of enhancements directly inside the GitHub UI:

• Real-time, customizable task boards for GitHub issues;
• Multi-Repository burndown charts, estimates, and velocity tracking based on GitHub Milestones;
• Personal to-do lists and task prioritization;
• Time-saving shortcuts – like a quick repo switcher, a “Move issue” button, and much more.

Add ZenHub to GitHub

Still curious? See more ZenHub features or read user reviews. This issue was written by your friendly ZenHub bot, posted by request from @cgilson.