TDD and waiting on dependencies

Question

I am on a fairly new team that is also new to TDD and Agile/Scrum. Currently we are developing a project that consists of web API and a native iOS and Android application, with a small team of devs working on each one. We were having a discussion about how to solve issues in developing concurrently and all had differing opinions and were looking for insight.

Right now, when we start a story we all branch our respective projects in Git for the story where the work sits through the approval process. Frequently, the native mobile application devs are stuck waiting for code on the web API end to move further in the process so that they can consume it and start the work.

Some argue that it is the web API dev's responsibility to mock that data and API endpoint from the start based on a defined contract then swap that code out for the code that will actually sit at that endpoint while the mobile developers work. The issues with this are that the mobile developers will still have a (shorter) waiting period while the data is being mocked and it will require more work on the web dev's end.

Others argue that the mobile developers should be mocking that data in their tests and develop using that mocked data on their end for their unit tests, letting their integration tests fail while the web API devs work on their code since the approval of the story depends on the two party's code in unison either way. The downside of this is that it still allows for the mobile devs to get ahead of the web devs and makes their testing and implementation of their UI much harder.

What are some best practices regarding this? Are either groups right, is a mix of the two groups right, or are neither of the groups right and there is another way to avoid this problem all together?

Answer 1

I've been a mobile dev in this situation.

We did both. The mobile team need mock data they control, so they aren't broken when the interface changes. The api team should mock the interface because its a better test that everything will work when they release.

But it boils down to a management issue. Either way solves the problem. One of you has to stop arguing about it and type some code.

In your case the mobile devs are the ones waiting, so presumably they have time to mock up some apis.

Answer 2

Since you are asking who should do the mockup in the development: client team or server team?

short answer "both together"

In my projects i like to worke like this

• define an api between client and server (i.e. a java or c# interface with method name, input parameters and output parameters or a rest signature)
• a human readable text format for the non standard datatype data that can be easily implemented in client and server code (i.e. xml, json)
• an interface usecae data prototype: when the client calls methodA of interface B with these parameters then the service will return this xml.

since client and server devs do this together we make shure that both needs are met

the result of this is 90% of the mockup code.

the clinet side starts implementing it-s own mock by implementing the java/c# interface that read the data prototype xml from a disk file. It then continues to write the code to convert between xml and internal object model (serialisation)

the server side starts implementing its service as a webservice that read the data prototype xml from a disk file. It then continues to write the code to convert between xml and internal object model ((de)serialisation)

if both client and server use the same language the (de)serialisation code has to be written only once

Answer 3

TDD is a funny thing. I understand thinking you need to wait on other teams to finish before you write your tests, however this isn't the case!

While your utilizing TDD, your more than likely going to be writing a lot of Unit Tests. These tests aren't intended to test a whole system, but instead one small section of it. These tests exist to prove that a function will work with the data provided to it, in however many circumstances (each circumstance would be a test). Doing this will force you to mock/stub objects because you need to control what comes in and out of the functions under test.

Because of this you don't need to wait on anyone for code. In reality, you should be mocking/stubbing objects to produce data you expect to come in to your functions, and simply make these mocks similar in functionality to what you expect those classes to do.

Answer 4

First, if you're going to follow scrum, then you don't have Web Api, iOS and Android teams: you just have your scrum team. If the existing teams are too large to all be part of one team (3-9 max for a scrum team), then you're in "scaled scrum" territory, where you'll essentially be running a scrum of scrum. There's different methodologies out there for this, but generally speaking, you'll have an overarching scrum team composed of the product owners from your smaller scrum teams. This overarching scrum team will have it's own product owner, who essentially owns everything. The backlog, then, filters down from the top. Where the main product owner maintains the full entire product backlog and each individual scrum team product owner maintains the backlog for that particular team.

In either setup, the process is still actually pretty much the same. There should be a PBI for the Web Api work and PBIs for each platform-specific piece of work. If the Web Api PBI is a dependency then the platform-specific PBIs cannot be worked on until that PBI is done, which means they have to wait until the next sprint. Organized in this way, everyone is still actively working on PBIs in the backlog, but you may not be able to deploy particular features in a single sprint when they have cross-cutting concerns. That's fine, and your product roadmap should account for these situations.

Answer 5

@Rhys Johns said it right - in TDD you are constantly making small stubs for testing your functions.

BUT. There are stubs and stubs... We shouldn't mix them or forget any kind of them.

If we'll recall that agile methods were accepted, we'll see that the start version of every piece of SW is a stub by itself. So, the server guys should start by creation of a stub, that only simulates the server for client guys. And client guys start by creation of a stub, that simulates the UI for users. On the SECOND stage they will do the version that will simulate the work with server. After that they'll show the info, simulated by server in the UI. The next step is the user work with the server-stub.

And on any stage we still use TDD, thus creating small stubs, testing separate functions.