Define the first scenario "Search repositories by keyword"

We start by writing a unit test for your scenario.
This Java object will represent a single flow of our application and will encapsulate the business rules behind this user story.
Going test first allow us to discover the various dependencies that our scenario needs and to define the project structure.
This package structure clearly reflects the intent of the application: all supported user stories sit on a package, and the boundaries should be as decoupled as possible from the rest of the application.
Add an end-to-end test for the first scenario

In order to actually explore the boundaries of our scenario, such as the UI interaction, we write a test that runs on a real device.
This test will exercise the scenario code and the android frameworks, and will remain red until we have implemented the required UI elements.
Thus, in our presentation package we are forced to deal with android specific concepts like activities, adapters and managed lifecycle.
We decide to use Robotium as our IT library as it make easier to write expressive and more robust tests, as independent as possible from the actual implementation.
Parse a search repository response into Java models

We decide to use Jackson as a Json parsing library for its performance, flexibility and annotation-based configuration.
To ensure maximum flexibility, we hide the ObjectMapper object with our own implementation, JsonConverter.
We use custom converters for every entity, so that the object creation must pass through the constructor.
This way our models remain immutable and we can enforce class invariants such as "startDate < endDate".
This also keeps Jackson as an implementation detail and we're free to swap for another library (like Gson) without touching our entities.
We make sure that entities that are Collections are treated as first class objects, because they represent a concept in our domain and may contain specific business logic.
Write a stub for the Github api

We write an implementation for the GithubApi interface that will provide predictable responses for every query.
That way we can run the entire application without having to rely on the Github servers, speeding up both testing and development.
Also, those mocked responses allow us to eliminate some duplication in the test classes.
Add a ScenarioDispatcher as a convenience central point to execute scenarios

The Dispatcher is the class that the boundaries will use to access the ability to run scenarios.
This is a major abstraction on how the scenarios are effectively executed: they might be run directly, put into a queue or scheduled for later, but the boundaries should not care about it.
We also choose to assign to the ScenarioFactory the responsibility for wrapping the actual scenario and the presentation on separate threads.
That might be an odd solution, but it works for now and we can refactor later if the need arieses.
Bridge the gap between the presentation layer and the android lifecycle.

Maintaining references to objects in Android can be dangerous because the platform may destroy them and reclaim the memory at any time.
We need a solution to decouple our business logic from the details of the android framework.
The two widely adopted solutions are an Event Bus and an Injection Framework.
The bus allow us to broadcast a certain event without holding an explicit reference to the objects that will respond to this event.
Injection allow us to add dependencies to the object that we can't construct, like activities and fragments, makes our architecture cleaner and with less boilerplate code and makes writing tests easier.
Define a Controller to drive the activity behavior

The best way to TDD an activity is to write a controller for it.
You'll start to test the behavior that you want to accomplish with that component, like handling a search query or update the ActionBar information.
Notice that there are no notions of intents or instanceState or lifecycle callbacks in our controller.
That's a good way to separate how a certain behavior is accomplished from the behavior itself.
Create a search configuration and make the test pass

We can now create a searchable configuration and use the controller inside the activity to make the test pass.
All Android related boilerplate is confined inside the activity while the controller encapsulates the logic behind it.
We can remove boilerplate duplication (savedInstanceState, findViewById, Intent navigation) using annotations or injecting helpers, depending on our need.
We'll start using these tools when our domain is more defined.
Add test fixtures to the real Github service

Our integration tests are green, but we are running those tests against a mock server.
In order to test that our predictions are correct and that the apis are stable, we can exercise our code against the live service.
This step can be taken in parallel with the development of the rest of the application code.
Since we are exploring another boundary, the api service, we wrap the implementation details with our own interface, the GithubApi.
We pick Retrofit as a REST framework for its ability to run both on Android and on JVM.
Rewrite Service injection using multiple levels

This small refactoring allow us to easily swap one service for another, while keeping our IT run in mock mode.