datastore: Protobuf switch

[rakyll]

I started to work on protobuf switch for datastore.

This will be the first part of changes related to protobuf. We also need some internal cleanup and remove unit tests that are covered by regressions.

Just because Protobuf.js doesn't have getters/setters, our code base if full of underscored var names. I tweaked jshint global settings not to annotate each file.

[rakyll]

protobufjs is the enemy of JavaScript styling. I fixed a bunch of other issues for the initial release. PTAL.

As I pointed in the PR desc, we need to clean entity.js up, I generally don't like the namings for conversion functions. We also duplicate ourself much in unit testing. What's covered in regressions is being covered in unit tests again and again.

[stephenplusplus]

This clobbered #108 :(

We also need some internal cleanup and remove unit tests that are covered by regressions.

I would go the other way around: unit tests should cover every piece of functionality we're writing.

our code base if full of underscored var names.

Oh well, it was nice while it lasted!

PTAL

On it 👍

[rakyll]

I would go the other way around: unit tests should cover every piece of functionality we're writing.

Most of the unit tests are mocking the API server. If we have integration tests, why do we need to maintain mocks?

[stephenplusplus]

Most of the unit tests are mocking the API server. If we have integration tests, why do we need to maintain mocks?

I think we need to clarify the balance. In a perfect world, all the tests we write could be ran against a real endpoint. But, the reasons I can think of that doesn't work on this project:

• slow,
• can't work offline,
• Travis can't run them,
• it actually costs money.

Since unit tests are meant to test the functionality of the code, we have to trigger responses, sometimes success, sometimes errors. The nature of the beast is writing mocks to allow us to do that.

I think the balance should be:

• write unit tests for everything,
• find a way to make mocking responses easier,
• use integrations to test "does the API work as the readme says?"

Even better would be removing the mocks from the unit tests, and just throwing the same tests at a backend.

[rakyll]

find a way to make mocking responses easier,

What about introducing https://github.com/pgte/nock to the unit tests? It also records HTTP requests and can generate mock objects -- requires less maintenance work too.

[rakyll]

Could we merge this as it is and I can send cleanup on a later CL?

[stephenplusplus]

Sgtm

On Monday, August 18, 2014, Burcu Dogan [email protected] wrote:

Could we merge this as it is and I can send cleanup on a later CL?

—
Reply to this email directly or view it on GitHub
#112 (comment)
.