Writing unit tests effectively for legacy Android codes
Native Android codes has a very bad nature, which it tends to make developers mix logic codes with UI codes in a single class, usually Activity or Fragment. It has become a super common practice for Android developers to write most of the logics in Activity, Fragment, or Service. Very few people would feel anything wrong with doing this, because this is so nature for Android.
However, when the time comes to write unit tests for these codes, they become nightmare. Testing the Activity/Fragment lifecycle in unit test is already very hard, and testing methods that requires lifecycle to setup variables for it is even harder. It's not uncommon for a one line code change takes a day or even longer just to write a very simple unit test. When you sit in front of the monitor and look at the code which the UI and logic are all mixed together, it's really tough to even figure out where to start writing an unit test for it. I, unfortunately, had to write unit tests for hundreds of thousands of lines of legacy Android codes like this. After going through a painful period and learning several lessons in a hard way, I gained some experiences about how to do this, and I believe this will be beneficial to everybody.
Outline/structure of the Session
The session will include the follow:
- Why legacy Android codes are extremely difficult to write unit test for
- Recommended way to write your new Android code
- Writing unit tests against Activity/Fragment without actually seeing the UI
- Breaking dependencies of legacy Android codes to get them under test harness
The audiences will be able to learn how to write unit tests effectively when they are dealing with legacy Android codes, as well as writing new Android codes
Developers and testers
schedule Submitted 3 years ago
People who liked this proposal, also liked:
Jiun-Yang(John) Hsu - From Agile to DevOps -- The journey we had and ahead of usJiun-Yang(John) HsuAdvisory Software Engineer -- Mobile Development and DevOpsIBM
schedule 3 years agoSold Out!
In IBM we have adopted Agile for several years. While we thought we were good enough, we can actually do better with DevOps. Our release cycle was 6~12 months, and that's far slower than standard DevOps teams. So we decides to adopt DevOps about 15 months ago. However, in a huge company like IBM, adopting something as big as DevOps is very difficult. Our experience with Agile adoption gave us a pretty good idea that this is not easy. But this is what we must do, and we can afford to fail. So, we did the following:
- Made a lot of changes in the process and organization. For example, merging functional test team with development team. We also adopted many new processes within the development teams
- Worked very hard in getting the support from managers and executives of all levels. This is probably the most important thing for every company who want to adopt DevOps, and we definitely had to spent a lot of effort to make sure we have this.
- Delivered many educations targeting every roles in software project. We delivered various education sessions to different roles, like developers, testers, and managers.
- Learned and explored knowledge and tools. We have specialized team working on investigating tools and studying DevOps related knowledge, and share with everyone.
- Invested tons of efforts in developing automation tests of all types, as well as modifying existing automation tests to fulfill DevOps requirement.
- Greatly improved our build process and scripts. We have a centralized build team helping us do this, and each development team also worked on improving their build scripts.
I'll share what we did specifically in the areas above. As always, this is a continuous improvement and continuous learning process, and you're never "done" with DevOps. So, I'd like to discuss some topics that we don't have an answer as of now:
- Centralized build team or not? Most DevOps practitioners will say no to centralized build team, but large companies like IBM all have super complicated compliance that applies to build machines. If we don't use the service of the centralized build team, the product team will have to handle the compliance, which is not fun at all.
- Find and fix every single defect before releasing to production, or move that effort to production environment monitoring and improve the recovery process of the production environment? This is especially valid for system test, where the multiple days long run is needed to find some bugs. Those tests can only find about 20% of defects, so is the result worth the effort?
This topic should be very interesting for those who want to or just started to adopt DevOps in a relatively large organization. Applying DevOps in a web startup is what many people had already done. Applying DevOps in a large organization with on-premise products and huge amount of legacy codes and tests is a very different story.
Jiun-Yang(John) Hsu - Behavior-Driven Development for Android projectsJiun-Yang(John) HsuAdvisory Software Engineer -- Mobile Development and DevOpsIBM
schedule 3 years agoSold Out!
Behavior-Driven Development(BDD) has been out there for several years, and had gain big momentum in software development. However, only few people have used that in Android projects. As part of our DevOps adopting effort, we started to investigate various BDD tools for mobile, and finally decides to use Cucumber-Android + Espresso as our acceptance test tools. However, this doesn't mean that we feel other tools are inferior. In fact, Cucumber-Android is the youngest one among the tools we investigated. Another interesting tool we use is Espresso, which was just released in late 2013. We compared it with the popular Robotium and decided to go with it. The primary reason was that we are doing Continuous Delivery, and automation tests in a CD pipeline needs to be stable and fast. Since the tools here are quite new, and this is an area where few people had explored, I think it will be very interesting and valuable for AgileDC audiences.