Tag: Android

Setting up Travis CI in Android

Setting up Travis CI in Android

If you are developing using TDD you should run your tests to be sure that you don’t break something in every TDD phase. But we are not perfect and we can commit changes that break our system and we should have something that can alert us if we are doing something wrong asap. This is going to be a short guide on getting set and ready with Travis CI in Android. Before we continue, you need to have an Android Studio project already set up. Now let’s get down to business.

Prerequisites

  • Create a github repo for your project
  • Head over to the root of your project and create a .travis.yml (More on this later)
  • Still at the root of your project, create a folder/directory called licenses; this directory will help in exporting your license agreements such as sdk license agreement from your local machine to the build environment.
  • Now head over to your sdk location and locate a folder/directory called licenses, copy its contents then go ahead and paste them inside the licenses folder/directory you created previously at your project root.
  • You’re now set up, just do a git init, add all your files to git then push your code to Github.

Setting up Travis CI

Here is where Continous Integration comes into play. Every time that you push changes into a branch in your system you can check if everything is ok before you merge this branch into Master (assuming you are using git). What to check? Well, this is up to you and your team members to decide.

I keep my promises! , lets now talk about .travis.yml mentioned earlier. So this is just a file that tells your build machine how it should be configured and also provides the necessary tools and information to get your build system up and running.

So how does this file look like? Here’s the code, you can copy paste it but ensure you go through it to have a grasp of what’s going on.

You can decide to paste it directly to your code then commit and push the changes or paste it in your Github Repo then pull the changes, either of these two will work fine.

Travis provides the service for free but your repo in Github must be public and the free URL is different from the premium URL.

After visiting Travis, sign in with Github. Search for your Github repo then add it. Travis will go to your repo, locate the .travis.yml file and do the rest. Hopefully, if you followed every step correctly, your build should be successful and the repo should turn green with the badge at the top indicating build passing.

Bonus

It’s awesome looking at that badge from your repo. So to add it to your repo, go ahead and click on it. A pop up will show with the url of the badge. Copy the url then paste it in your README file. Here’s an example of how the file should look like inside your README file.

Hooray! Your CI should now be up and running. Thanks for your time.

Happy Coding!

UI Testing with Espresso

UI Testing with Espresso

Introduction

It is normal for developers not to be concerned about testing at the beginning when still learning how to program, but as they get involved in larger projects and critical software, getting involved in testing will be inevitable. According to the documentation, Espresso is targeted at developers, who believe that automated testing is an integral part of the development lifecycle.

Software testing is the last thing on the mind of someone who just wants to code and get it going, as long as there are no bugs it is good to go. But that can be costly if done in companies where a minute of failure will cost a lot of money. I was at a GDG (Google developer group) event where a speaker who works at a well known international company said that the company had lost millions at a point, and it was due to the fact that a developer had forgotten to test the UI which was to book international flights for  customers. It was charging the customer’s account but displayed that the transaction was unsuccessful so the customers kept booking assuming that it was because of poor network, imagine how much was lost with that kind of error. Well, testing might not be top priority if I am making a quick to-do list app 🙂 , but it is good practice to properly test your code.

Espresso is a testing framework that includes a set of APIs that simulates and schedules user interactions to help test the user interface and with these tools you can automate the process of testing. So instead of punching, slapping, poking or pressing your phone screen to test if your app works fine as expected, Espresso can do this for you while you relax 🙂 .

Normally if you were to manually test your Android app, you will start the appfind the view you want to test, and verify that the expected output or behavior was what occurred. If you understand these steps then testing should’t be a problem.

According to the documentation, to create an Espresso test, create a Java class that follows this programming model:

  1. Find the UI component you want to test in an Activity  by calling the onView() method, or the onData()method for AdapterView controls.
  2. Simulate a specific user interaction to perform on that UI component, by calling the ViewInteraction.perform() or DataInteraction.perform()method and passing in the user action (for example, click on the pay button). To sequence multiple actions on the same UI component, chain them using a comma-separated list in your method argument.
  3. Repeat the steps above as necessary, to simulate a user flow across multiple activities in the target app.
  4. Use the ViewAssertions methods to check that the UI reflects the expected state or behavior, after these user interactions are performed.

Code time!

Lets take a look at a code snippet below

The first thing done is the search for the view, the withId() is a view matcher, while the check() is the view assertion. So when the code runs it checks if the textView with Id R.id.textView is displayed and if it finds the view the test will pass, otherwise the test will fail.

To properly demonstrate, let us test a simple app that copies a text from an EditText to another EditText view.

Below is the UI.

 

Below is the XML and MainActivity.java code to see what’s under the hood:

activity_main.xml

MainActivity.java

 

The EditText with Id textA is the first view at the top, while textB is the second view below textA but above the button (copyBtn).

To test this app let us create a new instrumented unit test:

I can name mine MainActivityTest:

Start testing!

So this is how my MainActivityTest class looks initially:

You will normally start the class with @RunWith(AndroidJUnit4.classwhich helps control launching the app and running UI tests on it. ActivityTestRule is a rule that provides functional testing for a specific single activity. All these annotations indicate to Android that specific parts of the test code need special processing. @Test indicates where we are testing what we are interested in.

The @Test method can have any name, but for readability be careful to give it a name that indicates the purpose of the test.  I will just quickly name mine TestEditTextA.

So the above test is just a simple test that writes some text on the first EditText view and verifies if what was written on that same EditText (textA) is what appears.  To run the test you right-click on the Java file and select ‘run’, in this case ‘RunMainActivityTest’.

If it is successful you will see a green bar as shown below, also stating how many tests were carried:

 

If it failed for some reason, the bar will be red and you will see the log output for example:

 

Full Code!

The test source code shown above isn’t the main test since it does not test the button click and the copying, below is the full code for the test:

So as shown, the text “123456” is written onto the first EditText (textA) then the button (copyBtn) is clicked and then the second EditText (textB) is checked if the text was truly copied, if so then the test passes and the app works as expected. You can get the full source code at EspressoTutorial.

Read More Read More

Dagger – Dependency Injection Introduction

Dagger – Dependency Injection Introduction

In this article, I will introduce you to the concept of dependency injection with very simple examples.

This article is the first in a series on the topic of Dependency Injection(DI) and why and how to use dagger for dependency injection on android.

 

Dependency Injection (DI) is providing an object the objects it needs instead of having it create them itself. Dependency injection is a (scary) term that is used to express a simple concept of giving an object its instance variables. It is a concept we use daily without knowing. Please bear with me…

Dependency injection can be done is several ways; Constructor injection or Setter injection. We can use a library such as Dagger for such purpose. However, using such a library is not a requirement. You can instantiate a class passing a dependency (object) into its constructor or set the dependency using a setter.

I’ll illustrate below, dependency injection without a framework or library, with a simple example;

1. Without dependency injection;

 

2. With dependency injection;

a) Constructor injection

 

b) Setter injection

 

So, there you have it. Dependency injection is simply passing an object an instance variable.

Some examples of dependency injection include;

  1. Allows your object to be flexible and configurable. In the above example, you could pass in millet flour, maize flour or even sorghum flour which then determines the type of Ugali you get.
  2. Makes your code loosely coupled. This will be important during code refactor (a.k.a changing code for some reason or other, but mainly to make it better). In the above example, if the behavior of Flour, say Flour price rises, the way ugali is cooked doesn’t change, so less code change. This also improves testability of your code; you can inject mock flour and water to test the Ugali object in unit testing.

Disadvantages include;

  1. Possible reliance on a dependency injection framework. In our case, dagger

 

 

Since I want to keep this short and simple, I’ll leave it there for now. If you want to read more on the dependency injection topic and the broader Inversion of Control (IoC) topic, here are some links;

  1. Wikipedia – Dependency Injection
  2. DZone – A beginner tutorial
  3. Dependency Injection for beginners

Next, I’ll look at a more complex scenario and how we can use dagger to do the heavy lifting for us.

In the meantime;