Unit testing on Android
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Deniz, Buşra
Android development and testing go hand in hand. When it comes to unit testing there are plenty of frameworks out there. During this session, Busra Deniz will be presenting a fine selection of tools and perspectives that could help you decide what to use and how to use in your next project. Some of the topics that will be covered are benefits of unit testing, how to automate UT and how to measure code coverage. And since it'a developer conference there will be code examples in Gradle, Junit, Mockito, Robolectric, Jacoco and much more.
 Hi. I will talk about you testing on Android today. Before starting, I want to introduce myself. I am Bishra. I am from Turkey, Istanbul. I am a mobile software developer in Netash. Netash is a company in Turkey. It develops solutions. I am also a master of mobile team in Netash. We are developing native SDKs for iOS and Android using Google WebArtsy Library. It enables real-time communication, audio and video SDK, audio and video communication. I am also co-organiser at Woman Techmakers Istanbul and GDG Istanbul communities. We are organizing technical events in Istanbul. I became co-author of an Android book in Turkish English. It is such like Android cookbooks. You can see my contact info at the screen. And today, I will talk about shortly unit test definition. After that, I will mention why we need to test our code. After this explanation, I will talk about some unit test frameworks for Android. After that, we will end with a QA session. Let's start unit test. Say the list of unit test is testing single unit of code. This unit can be a method class component or whatever you want to test. It is any part of your code. It is called as a software under test. Before you start to implement your unit test, you should define your software under test. Basically, unit test gives us the ability to verify that our methods are expected. That is to say that for any function, given a set of inputs, we can determine if the function is returning the proper values or will gracefully handle failures during the course of execution should input be provided. In order to write good unit test, you should make each test independent to all the others. Any given behavior should be specified in one and only one test. Otherwise, if you later change the behavior, you will have to change multiple test cases and your maintenance cost will be bigger. Also, you should name your unit test clearly and consistently. Maintenance is too hard if you don't know what you are trying to maintain. You can write unit test before and after featuring implementation is completely your choice. As a summary, the goal of unit testing is to isolate each part of the program and show that these individual parts are works expected. Our works are correct. Unit test provides a C-trick writing contract that the piece of code must satisfy. Why we need to write unit test? Why we need to test our code? I will mention shortly unit test benefits. First benefit is unit test enables fixing bugs early. Unit testing finds problems early in the development cycle. This includes both bugs in program and implementations or flaws or missing parts of specification of this unit. The cost of finding a bug in the development cycle always is lower than processes after implementation. The second advantage is useful documentation. Unit testing provides a sort of living documentation of system. When new developers need to learn what functionality is provided by a unit and how to use it, she can look at the unit test to gain a basic understanding of this unit's interface. Unit test cases and by the characteristics that are critical to success of unit, this characteristic can indicate or inappropriate use of a unit. The other advantage is reducing testing time. Unit test covers the basic cases of your software. The next level of software testing can include more complex scenarios. For example, checking null parameters can be handled in unit test. So the next cycle of software tests, you don't need to consider null parameters behaviors. And the last one is the refining design. UT always forces you to design software parts that can test easily. While you are writing unit tests for existing code, you will realize that it's not too easy. Your code should be proper to write unit tests, should be proper in order to isolate your parts of your suit. By this way, you need to refactor and refine your code so as to write successful unit test cases. And it improves your software design. Today I will mention some Android unit test frameworks. In this screen, you can see the most popular Android unit test libraries. Since I have limited time, I cannot talk about all of them. But as a general view, the J unit is the most popular unit test framework, especially for Java developers. I think everybody has already known it. Mockito, PowerMock and EaseMock are also familiar, I think. They are mocking libraries. Robo-electric, Robo-tube and Espresso are frameworks for UI unit testing. Let's start with J unit. J unit is a simple framework to write repeatable and automatic test cases. I think it's the most popular unit test framework for Java ecosystem. And I think you have already known it and you have already used it deeply. But I want to mention it shortly. It has some valuable features in order to write unit test easily and fast. First of them asserts J unit provides overloaded assertion methods for all primitive types and objects and arrays. The parameter order is expected value followed by actual value and you can add optionally a string message, a fail message. And the other test set up and tear down, J unit provides test set up and tear down methods in order to prepare test data and test environment before the test cases. And tear down method, reset these test data and environment after running test cases. Exception testing, you can verify that code controls exceptions as expected with J unit. Test units, unit test cases can be organized into test suites for better management. You can run your test suite by suite. When you run class that suite is defined inside, it will run all the tests in all your test suites. Rules, rules always very flexible addition and redefinition of the behavior of each test method in a test class. Testers can reuse or extend one of the provided rules. And next one, integration with the system. J unit can easily integrate with the popular build system like gradle and may one. And you can also see J unit gradle dependence at the bottom of the page. This is a simple example of the J unit test. You can see set up tear down and test method. And you can see before test after annotation. With this annotation, you will not need to add some special words to all your methods names. They identify this method is test method, this is set up method. And J unit has different annotations. Test before, after, before class, after class and ignore. For example, ignore means that these test cases will not be run. And assertion. J unit provides overloaded assertion methods for all primitive types, projects and arrays. And as you see, assert, there are many various assert method in J unit. Assert, not, you can find lost of methods. And test suites in J unit gives us ability to organize into test suites for better management. You can manage organize your relevant test cases. And when you start to run these classes, your all suites will run by run one by one. But you should be careful about adding run with. You should define run with annotation. And when you are using J unit, you cannot make mock operation by using J unit. So you need to mock framework. And mock is a mocking framework that tastes really good. It has a really easy and simple API. And as you know, mock is not single mocking library for Android. Easy mock and power mock are also familiar. By the way, mock initially started with a fork from easy mock. And power mock assert that it is a strong framework that extends other mock libraries with more powerful capabilities. Power mock uses a custom class loaders and byte code manipulation. So you can mock private methods, static classes, static methods and construct by using power mocks. But you can test. But as a disadvantage of byte code manipulation is affecting code coverage, you can take wrong or the captive test coverage results by using power mocks. So I am using mock it generally. Also, the community voted mock it the best for java. It has a simple and easy API to use. First, main API is mock method and mock annotation. It creates mock objects. The second API is spy. Spice is partial mocking. Real methods are in mock but still can be verified and stopped. Inject mocks, annotation, inject mocks into tested objects automatically. And the final API is verified. It checks methods were called with given arguments or desired numbers. And at the bottom of the page, you can see the mock to gradle dependency. And there is a simple example for mock. At the first example, we mocked a list and verified it with one element edit and then clear method code. In the second example, it's the same with first but we used mock annotation. If you use mock annotation, you should call mock annotation dot init mocks before use mock objects. And spy example, there are also spy examples. As mock example, we spied a list and verified that with one element edit and then clear method code. When we use spy annotation in state of spy method in the second example, you can use both of them. It's your choice. While you are using J unit and mocking and running your test cases with J unit and mock to, you will realize that your test cases will need an emulator or a real device. And while running test, it's too slow and building, deploying and launching the app often takes a minute or more. It's not comfortable and desirable environment for a developer. And there is a, there must be a better way. It's when you try to run your Android test directly from inside in your IDE. And perhaps you will take this exception, runtime exception stop. And solution is the Roboelectric. Roboelectric lets you run your test case on your workstation or on your CI environment in a regular JVM without an emulator or device. Roboelectric makes this possible by rewriting Android SDK classes as they are being loaded and making it possible for them to run on a regular JVM. If you run your test case with Roboelectric runner, you will not need an emulator or devices. Roboelectric also supports resource handling. You can also use the find with by ID methods to search in a VIV. In this example, when you click to login button, login activity should be triggered. We set up a welcome activity with set up activity method of Roboelectric. Then we trigger perform click method of our code by simulating clicking login button. After that, we assert that whether the next activity is a queue to expected activity. Roboelectric gives us ability to test our UI but not UI design. We can test UI interactions and elements, availability. And you can see the Roboelectric gradle dependency at the bottom of the page. And it's all about UT frameworks on Android from my site. But at the end of my presentation, I want to answer this question. How much should we test our code? When should we stop? I think we should measure our test coverage before deciding that your tests are enough. According to the results of your coverage report, you can stop implementing unit tests. When we consider unit test cost and maintenance cost, it should be completely your decision and it's up to your project priorities. And Yagoko is a well-known and free code coverage library for Java. It supports instruction, branch line method and class coverage. It provides very many detailed report one by line. So I love it and I'm using it. And this is the example, a parent of a class in Yagoko report. The green lines represents parts of cost which were fully covered by test. The yellow line means that given branch was not fully covered because it's conditionally evaluated to true. And the red line was never executed by our test. According to these reports, you can decide that your test case is enough or not enough. And thanks for watching my presentation.
 Hi. I will talk about you testing on Android today. Before starting, I want to introduce  myself. I am Bishra. I am from Turkey, Istanbul. I am a mobile software developer in Netash.  Netash is a company in Turkey. It develops solutions. I am also a master of mobile team  in Netash. We are developing native SDKs for iOS and Android using Google WebArtsy Library.  It enables real-time communication, audio and video SDK, audio and video communication.  I am also co-organiser at Woman Techmakers Istanbul and GDG Istanbul communities. We  are organizing technical events in Istanbul. I became co-author of an Android book in Turkish  English. It is such like Android cookbooks. You can see my contact info at the screen.  And today, I will talk about shortly unit test definition. After that, I will mention  why we need to test our code. After this explanation, I will talk about some unit test  frameworks for Android. After that, we will end with a QA session. Let's start unit test.  Say the list of unit test is testing single unit of code. This unit can be a method class  component or whatever you want to test. It is any part of your code. It is called as  a software under test. Before you start to implement your unit test, you should define  your software under test. Basically, unit test gives us the ability to verify that our  methods are expected. That is to say that for any function, given a set of inputs, we  can determine if the function is returning the proper values or will gracefully handle  failures during the course of execution should input be provided. In order to write good  unit test, you should make each test independent to all the others. Any given behavior should  be specified in one and only one test. Otherwise, if you later change the behavior, you will  have to change multiple test cases and your maintenance cost will be bigger. Also, you  should name your unit test clearly and consistently. Maintenance is too hard if you don't know  what you are trying to maintain. You can write unit test before and after featuring implementation  is completely your choice. As a summary, the goal of unit testing is to isolate each part  of the program and show that these individual parts are works expected. Our works are correct.  Unit test provides a C-trick writing contract that the piece of code must satisfy. Why  we need to write unit test? Why we need to test our code? I will mention shortly unit  test benefits. First benefit is unit test enables fixing bugs early. Unit testing finds  problems early in the development cycle. This includes both bugs in program and implementations  or flaws or missing parts of specification of this unit. The cost of finding a bug in  the development cycle always is lower than processes after implementation. The second  advantage is useful documentation. Unit testing provides a sort of living documentation of  system. When new developers need to learn what functionality is provided by a unit and  how to use it, she can look at the unit test to gain a basic understanding of this unit's  interface. Unit test cases and by the characteristics that are critical to success of unit, this  characteristic can indicate or inappropriate use of a unit. The other advantage is reducing  testing time. Unit test covers the basic cases of your software. The next level of software  testing can include more complex scenarios. For example, checking null parameters can  be handled in unit test. So the next cycle of software tests, you don't need to consider  null parameters behaviors. And the last one is the refining design. UT always forces you  to design software parts that can test easily. While you are writing unit tests for existing  code, you will realize that it's not too easy. Your code should be proper to write unit tests,  should be proper in order to isolate your parts of your suit. By this way, you need  to refactor and refine your code so as to write successful unit test cases. And it improves  your software design. Today I will mention some Android unit test frameworks. In this  screen, you can see the most popular Android unit test libraries. Since I have limited time,  I cannot talk about all of them. But as a general view, the J unit is the most popular  unit test framework, especially for Java developers. I think everybody has already known it. Mockito,  PowerMock and EaseMock are also familiar, I think. They are mocking libraries. Robo-electric,  Robo-tube and Espresso are frameworks for UI unit testing. Let's start with J unit.  J unit is a simple framework to write repeatable and automatic test cases. I think it's the  most popular unit test framework for Java ecosystem. And I think you have already known  it and you have already used it deeply. But I want to mention it shortly. It has some  valuable features in order to write unit test easily and fast. First of them asserts J unit  provides overloaded assertion methods for all primitive types and objects and arrays. The  parameter order is expected value followed by actual value and you can add optionally  a string message, a fail message. And the other test set up and tear down, J unit provides  test set up and tear down methods in order to prepare test data and test environment  before the test cases. And tear down method, reset these test data and environment after  running test cases. Exception testing, you can verify that code controls exceptions as  expected with J unit. Test units, unit test cases can be organized into test suites for  better management. You can run your test suite by suite. When you run class that suite is  defined inside, it will run all the tests in all your test suites. Rules, rules always  very flexible addition and redefinition of the behavior of each test method in a test  class. Testers can reuse or extend one of the provided rules. And next one, integration  with the system. J unit can easily integrate with the popular build system like gradle  and may one. And you can also see J unit gradle dependence at the bottom of the page.  This is a simple example of the J unit test. You can see set up tear down and test method.  And you can see before test after annotation. With this annotation, you will not need to  add some special words to all your methods names. They identify this method is test method,  this is set up method. And J unit has different annotations. Test before, after, before class,  after class and ignore. For example, ignore means that these test cases will not be run.  And assertion. J unit provides overloaded assertion methods for all primitive types,  projects and arrays. And as you see, assert, there are many various assert method in J unit.  Assert, not, you can find lost of methods. And test suites in J unit gives us ability  to organize into test suites for better management. You can manage organize your relevant test  cases. And when you start to run these classes, your all suites will run by run one by one.  But you should be careful about adding run with. You should define run with annotation.  And when you are using J unit, you cannot make mock operation by using J unit. So you  need to mock framework. And mock is a mocking framework that tastes really good. It has  a really easy and simple API. And as you know, mock is not single mocking library for Android.  Easy mock and power mock are also familiar. By the way, mock initially started with a  fork from easy mock. And power mock assert that it is a strong framework that extends  other mock libraries with more powerful capabilities. Power mock uses a custom class loaders and  byte code manipulation. So you can mock private methods, static classes, static methods and  construct by using power mocks. But you can test. But as a disadvantage of byte code manipulation  is affecting code coverage, you can take wrong or the captive test coverage results by using  power mocks. So I am using mock it generally. Also, the community voted mock it the best  for java. It has a simple and easy API to use. First, main API is mock method and mock  annotation. It creates mock objects. The second API is spy. Spice is partial mocking. Real  methods are in mock but still can be verified and stopped. Inject mocks, annotation, inject  mocks into tested objects automatically. And the final API is verified. It checks methods  were called with given arguments or desired numbers. And at the bottom of the page, you  can see the mock to gradle dependency. And there is a simple example for mock. At the  first example, we mocked a list and verified it with one element edit and then clear method  code. In the second example, it's the same with first but we used mock annotation. If  you use mock annotation, you should call mock annotation dot init mocks before use mock  objects. And spy example, there are also spy examples. As mock example, we spied a list  and verified that with one element edit and then clear method code. When we use spy annotation  in state of spy method in the second example, you can use both of them. It's your choice.  While you are using J unit and mocking and running your test cases with J unit and mock  to, you will realize that your test cases will need an emulator or a real device. And  while running test, it's too slow and building, deploying and launching the app often takes  a minute or more. It's not comfortable and desirable environment for a developer. And  there is a, there must be a better way. It's when you try to run your Android test directly  from inside in your IDE. And perhaps you will take this exception, runtime exception stop.  And solution is the Roboelectric. Roboelectric lets you run your test case on your workstation  or on your CI environment in a regular JVM without an emulator or device. Roboelectric  makes this possible by rewriting Android SDK classes as they are being loaded and making  it possible for them to run on a regular JVM. If you run your test case with Roboelectric  runner, you will not need an emulator or devices. Roboelectric also supports resource handling.  You can also use the find with by ID methods to search in a VIV. In this example, when  you click to login button, login activity should be triggered. We set up a welcome activity  with set up activity method of Roboelectric. Then we trigger perform click method of our  code by simulating clicking login button. After that, we assert that whether the next  activity is a queue to expected activity. Roboelectric gives us ability to test our UI  but not UI design. We can test UI interactions and elements, availability. And you can see  the Roboelectric gradle dependency at the bottom of the page. And it's all about UT  frameworks on Android from my site. But at the end of my presentation, I want to answer  this question. How much should we test our code? When should we stop? I think we should  measure our test coverage before deciding that your tests are enough. According to the  results of your coverage report, you can stop implementing unit tests. When we consider  unit test cost and maintenance cost, it should be completely your decision and it's up to  your project priorities. And Yagoko is a well-known and free code coverage library for Java.  It supports instruction, branch line method and class coverage. It provides very many  detailed report one by line. So I love it and I'm using it. And this is the example,  a parent of a class in Yagoko report. The green lines represents parts of cost which  were fully covered by test. The yellow line means that given branch was not fully covered  because it's conditionally evaluated to true. And the red line was never executed by our  test. According to these reports, you can decide that your test case is enough or not  enough. And thanks for watching my presentation.
_droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_0_2447.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_2448_2531.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_2532_3935.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_3936_4247.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_4248_4871.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_4872_5171.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_5172_8567.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_8568_10367.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_10368_11243.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_11244_11567.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_11568_11651.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_11652_14951.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_14952_19295.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_19296_19499.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_19500_21971.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_21972_23123.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_23124_23171.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_23172_25079.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_25080_28295.png _droidconDE_2015__Busra_Deniz___Unit_testing_on_An_X0ZFhqYanpg_28296_29437.png