Tag Info

Hot answers tagged

35

This is a conversation you should be having together, discussing the requirements and pros and cons of different formats. If one side or the other is dictating what happens, you're going to end up with bad software and an unhappy team.


10

The advertised cycle of TDD is write tests until they fail then hack at the code until they pass again and then refactor while keeping all test succeeding. When the spec changes you will need to remove the old tests that would verify a violation of the new spec and write new tests that will verify the new spec.


8

You most definetly should contribute to how the format and structure of the JSON should look like. I see it more than often that the front-end engineers, the API consumers, is the ones knowing how the data-structure should be. You are the one going to use the data, format it, loop through it and work with it. You should have an opinion on how you want it ...


3

TDD "by the book" has a specific cycle, and specficially for changing specs, this cycle should ideally look like this: write one test according to the new spec (-> "red") change the SUT ("subject under test") to match the new test; depending on the change, this might break some old tests (-> the new test goes "green", but the old tests become "red") Change ...


3

Welcome to the wonderful world of middleware development. It can be a lot of hard work and debate to develop a protocol, and no one should ever see the results. If you are on a small team, then avoid a dictator: have quick meetings with everyone to hammer out the protocol. Medium sized teams may wish to have representatives that work out the protocol. ...


2

Are there any clear (measurable?) guidelines (besides "it depends") for setting the degree of explicitness/inderection. Not many. The first is the Law of Demeter, which focuses on how many "steps" it takes to get to what you want, which directly relates to your question about indirection. Another is Tell, don't Ask. If you have some implicit state ...


1

You are asking two very different questions. The former one is not a generalization of the latter, because answering the first won't answer the second. There are many other things that might influence the second question, like how you would tackle transactions with multiple users and such. As for the first question, everybody agrees that a shorter ...


1

Contrary to the other answers, it is important to note that some ways of testing can become fragile when the system under test (SUT) is refactored, if the test is whitebox. If I'm using a mocking framework that verifies the order of the methods called on the mocks (when the order is irrelevant because the calls are side-effect free); then if my code is ...



Only top voted, non community-wiki answers of a minimum length are eligible