The document discusses different types of tests for Android applications including unit tests, functional tests, integration tests, and performance tests. It covers testing frameworks and tools like JUnit, FitNesse, and AndroidTestCase that can be used to write and run tests at the unit and integration level. The goal of testing is to ensure applications work as intended across all components of the system in a repeatable way.
This document introduces Flutter, an open-source mobile application development framework created by Google. It discusses why hybrid mobile apps are useful, and how Flutter addresses this through its ability to write once and deploy to both Android and iOS. Key features of Flutter that are highlighted include it being owned by Google, using the Dart programming language, and its widget-based architecture. The document then provides an overview of various Flutter development topics such as code editors, state management, animations, plugins, and profiling.
This document provides an introduction to developing mobile apps using Flutter. It discusses what Flutter is, its advantages over native and hybrid development. It covers the basic widgets in Flutter like Scaffold, AppBar, body and buttons. It demonstrates how to create a simple BMI calculator app as an example. Finally, it outlines the steps to learning mobile app development with Flutter, including improving architecture and adding features like camera, geolocation and APIs.
My Second Flutter Studyjam slides we covered these topics
- Themeing in flutter
- Flutter routes
- Flutter Data Models
- Isolates in Flutter
- asynchronous
Unit testing in Android involves testing individual units or components of an Android application to verify their correctness. This is done during development by the developer. The document discusses what unit testing involves, provides examples of unit tests for a number validator class and interval overlapping detector class, and discusses test doubles, constraints of unit testing in Android, where to unit test in an Android app, and test-driven development.
Android is an open-source, Linux-based operating system designed for mobile devices. It was developed by Android Inc., which was acquired by Google in 2005. The Android platform uses Java for application development and includes components like activities, services, broadcast receivers and content providers. Activities have a lifecycle that developers must understand. While Android offers opportunities for app development, challenges include software and device fragmentation and security issues. Key references for Android development include the Android developer website and Wikipedia.
Organizational study
Objective
Technology and associated platform
System architecture and design
Objective
Diagrams
Screen-shots
Future scope
References
This document provides an overview of Android app development. It discusses what Android is, its history and architecture. It describes the core components of an Android app like activities, services, content providers and intents. It also discusses Android Studio as the IDE, system requirements, how to develop a first app, common programming languages and learning resources. The goal is to introduce the key concepts for developing Android apps.
Flutter allows building beautiful native apps for iOS and Android from a single codebase. It uses Skia for rendering and widgets as basic building blocks. Dart is the programming language used, which is easy to learn and supports JIT and AOT compilation. Everything in Flutter is represented as a widget, from structural elements to layout properties. Widgets are composed together rather than using inheritance. Stateful widgets create State objects that can rebuild when the state changes. Flutter focuses on composition over inheritance and uses widgets as the fundamental building blocks.
Developing Cross platform apps in flutter (Android, iOS, Web)Priyanka Tyagi
Sharing slides from my Flutter talk at SV Code Camp: https://www.siliconvalley-codecamp.com/Session/2019/developing-cross-platform-applications-using-flutter-web-android-and-ios
This document provides an introduction to the Android platform, including:
- Android is an open-source, Linux-based operating system used for mobile devices. It includes features like integrated apps, SDK for developing apps, and customization options.
- The Android software stack consists of the Linux kernel, native libraries, Android runtime including the Dalvik VM, application framework, and applications.
- The document outlines how to set up the Android development environment in Eclipse, including installing the SDK, ADT plugin, and creating an Android Virtual Device for testing apps.
- It describes the basic components of an Android app - activities, services, content providers, and broadcast receivers.
- Steps are provided for
This document provides an overview of Flutter, a mobile application development framework. It discusses how Flutter allows building apps for Android and iOS from a single codebase, saving time and money compared to native development. It also covers why Dart was chosen as Flutter's programming language, Flutter's widget-based architecture, the types of widgets, and how to install Flutter and build a simple app. The goal is to introduce developers to Flutter and its benefits for cross-platform mobile app development.
Flutter is an open-source mobile app SDK developed by Google that allows building high-performance apps for iOS and Android from a single codebase. It uses Dart as its programming language, has beautiful Material and Cupertino widgets, supports hot reload for fast development, and compiles to native ARM code for high performance across both platforms. Flutter apps are fully reactive and use widgets to define all visual elements, making for a simple and consistent development experience.
Flutter is an open-source UI software development kit created by Google that allows developers to build mobile, web, and desktop applications from a single codebase. It uses widgets to build applications and provides tools for compiling code to native code. Flutter includes a rich set of widgets, support for plugins, and capabilities for hot reloading and running applications during development. Apps built with Flutter are high performance, can run on multiple platforms, and Flutter provides free and open tools for getting started with development.
The document describes how to build a simple two activity Android app in Android Studio. It includes steps to create a new project, add an empty activity, build a basic user interface with an EditText and Button, add logic to start a new activity on button click, and display data passed between activities. The steps demonstrate fundamental concepts of building Android apps such as activities, intents, and passing data.
Flutter is an open-source SDK developed by Google that allows building high-performance mobile apps for both Android and iOS from a single codebase. It uses its own rendering engine instead of webviews or native widgets, and has a thin C/C++ layer with most code implemented in Dart. Flutter supports hot reload which allows code changes to take effect instantly without losing app state. It is optimized for building 2D apps and supports features like camera, geolocation, and third-party SDKs.
This Presentation will give u information about Android :
1. Geocoding and Location Based Services Maps Finding Current Location Using Geocoder to get the current address of the user Plotting the current location on map
This presentation was presented in Android Only! 2011 conference on June 14th.
With more than 300 different Android devices out on 6 different platform versions, application developers are facing a real nightmare when trying validate that their applications really work on their customers' devices. While fragmentation is a new thing in Android platform, it is not new in software industry and there are several ways to deal with device fragmentation from testing point of view.
This presentation discusses most common approaches to tackle fragmentation from application developer's point of view and explains why testing for device compatibility is a must for any serious Android application developer.
The document provides an overview of testing on Android. It discusses test driven development (TDD) and behavior driven development (BDD). It describes the built-in Android testing framework, which is based on JUnit 3 and supports unit, functional, and activity tests. It outlines various test case types like ActivityInstrumentationTestCase2 that can be used to test Activities. It also documents utilities for writing tests, such as TouchUtils for simulating user interactions and ViewAsserts for making assertions about Views. The document guides the reader through an example of setting up an Android project and test project to apply TDD techniques.
How to setup unit testing in Android Studiotobiaspreuss
The document describes the steps to set up unit testing in an Android project using Android Studio, Robolectric, and JUnit. It includes adding dependencies for Robolectric and JUnit to the app/build.gradle file, applying the Robolectric Gradle plugin, creating a test folder and sample test class, and configuring the project structure and IDE integration so tests can be run from Android Studio.
This document discusses various types of tests for Android applications, including instrumentation tests, which run on an emulator or physical device, and unit tests, which run on a JVM without Android dependencies. It covers challenges with instrumentation tests like speed and dependencies on the device state. The document recommends writing business logic separately from UI code to make it more testable. It also provides information on frameworks like Robolectric, Mockito, and JaCoCo that can help with unit testing and code coverage of Android applications.
This document discusses testing for Android applications. It introduces unit and mock testing concepts in Java and demonstrates them with a Twitter example. It then provides an overview of Android testing, demonstrating an instrumentation test that tests an Activity. The document also discusses other Android testing techniques like ServiceTestCase and tips for testing Android applications.
This document discusses Android testing and provides information on unit testing. It covers unit test basics like the given-when-then structure. It also describes different types of test doubles that can be used in unit tests like dummies, fakes, stubs, spies, and mocks. Common unit testing tools for Android like JUnit and Hamcrest are also mentioned.
- The document discusses various topics around testing Android applications such as creating test projects, different types of tests (unit, integration, UI, etc.), testing frameworks like JUnit, using annotations, running and debugging tests.
- It provides an overview of key concepts and tools required for testing including testing on emulators and real devices, using mocks, assertions and view assertions in tests.
- The document demonstrates how to structure tests, write test cases with different assertions and annotations, and debug issues by running tests in Eclipse and from the command line.
User Interface Testing | Best Practices David Tzemach
Overview
What is GUI testing…?
The testing challenges
Should you automate your test..?
Test Recommendations
GUI testing Checklist
How to handle different GUI objects
SwaamTech, is an independent QA and Software Testing company helping clients to bring quality in there products. Contact us for testing of your SmartPhone App testing: support@swaam.com
The document discusses various techniques for testing Android applications including:
- Unit testing with JUnit and Espresso - Provides examples of finding views, performing actions, and checking states
- Monkey testing - A command line tool that generates random events to test app stability
- Useful resources like sample code from Google are provided to help developers learn Android testing
El documento argumenta que para lograr una educación inclusiva se necesita la colaboración y apoyo de toda la comunidad educativa, así como fomentar valores que construyan una cultura de paz e inclusión. También señala que es importante apoyar a los estudiantes con barreras de aprendizaje brindándoles las herramientas necesarias para su desarrollo. Concluye que una educación inclusiva requiere de una actitud de respeto por las diferencias y compromiso con no hacer de ellas un obstáculo para el aprendizaje.
La expresión corporal es una disciplina para adquirir un lenguaje corporal propio mediante la sensibilización del cuerpo, el dominio de los movimientos y la integración de la música. El documento describe los aspectos fundamentales de la expresión corporal y un proceso que incluye la toma de conciencia del esquema corporal, estímulos táctiles y visuales, y secuencias para desarrollar la percepción corporal y la comunicación a través de la interacción con otros.
The document discusses trusted computing and provides details on its architecture and uses. The trusted computing architecture uses a trusted platform module (TPM) to measure the boot process and software running on a device. It establishes a chain of trust from the hardware to the operating system and applications. While trusted computing aims to increase security and privacy, issues around its impact on privacy have prevented widespread adoption.
Espresso is a testing framework for Android that makes it easy to write reliable UI tests. It was developed by Google and released in 2013. The document discusses what Espresso is, similar automation frameworks, advantages of Espresso, and how to set it up and write tests using its API. Key aspects of the API are finding views with matchers, interacting with views using actions, and asserting view states with matchers.
Testing the User Interface - Coded UI Tests with Visual Studio 2010Eric D. Boyd
With the new Coded UI test in Visual Studio 2010, building automated tests for the user interface is no longer the unattainable Nirvana. In this session, we will explore the features of Coded UI tests in VS 2010. We will walk through how you record tests, add assertions and customize the resulting tests for increased automation. Finally, we will explore how to customize existing Coded UI tests and how to run them with your automated builds.
Introduction to android testing - oscon 2012OSCON Byrum
The document discusses testing for Android applications. It covers different types of tests like unit tests, functional tests, integration tests and performance tests. It also discusses test frameworks in Android like InstrumentationTestCase, AndroidTestCase and ActivityInstrumentationTestCase2. The rest of the document talks about test driven development and how to write tests for an Android temperature converter application.
Cross Platform Game Development with GDAP, December 2012jobandesther
This document summarizes different approaches to cross-platform game development. It discusses six main approaches: scripted, bytecode, C++, embedding a web browser, HTML5, and source code conversion. Each approach is evaluated based on factors like performance, native/non-native code, memory usage, API access, and source code visibility. The source code conversion approach allows for high performance, native code, low memory usage, full API access, and hidden source code. The document encourages choosing an approach based on technical merits rather than arbitrary criteria.
This Session
Why we need an enterprise system to control enterprise projects
Introducing the Microsoft solution Functional overview
Key principles for implementation
The document discusses configuration testing, which involves testing different variations of an integrated application against its configurability requirements. The objectives of configuration testing are to validate the application's ability to handle different functional variants, internationalization features, and personalization, and to identify failures related to these requirements. The document outlines preconditions for configuration testing, provides examples of test cases related to display configuration, and notes some tips for focusing testing on areas most relevant to the application.
Application Quality with Visual Studio 2010Anna Russo
The document discusses how to use Microsoft Test Manager, Visual Studio 2010, and Team Foundation Server 2010 to improve software quality through test management, test automation, and reporting. It covers managing testing resources with planning workbooks, improving reporting on test runs and bugs, creating automated tests using coded UI tests, and best practices for automated testing including integrating virtual machines for manual or automated testing in a test lab.
[AnDevCon 2016] Mutation Testing for AndroidHazem Saleh
Unit testing coverage is a great way to show us the amount of tested lines and branches of code, but is this really enough? The answer is "no" since unit testing coverage does not really fully measure the efficiency of the unit tests.
This is why there is a need for having techniques that show unit tests efficiency. Mutation testing is one of these powerful techniques. The main idea of mutation testing is to perform byte code modifications (mutations) to original Android app source code and then run app unit tests to check if they are strong enough to fail as a result of these mutations.
This session discusses mutation testing techniques, and demonstrates PIT as a powerful mutation testing tool for Android apps with demos.
Quality Best Practices & Toolkit for Enterprise FlexFrançois Le Droff
Quality Best Practices & Toolkit for Enterprise Flex
Presentation given at the French Flex User group : "les tontons flexeurs" on the 21st of July 2009
Author : Xavier Agnetti, François Le Droff (and Alex Ulhmann)
Copyright: Adobe
The document discusses Behavior Driven Development (BDT) using Microsoft Visual Studio 2010 and SpecFlow, including an overview of BDT, different BDT methodologies, using Gherkin syntax to write scenarios, integrating SpecFlow with .NET to generate and execute tests from scenarios, and a demonstration of BDT using SpecFlow.
The document discusses Behavior Driven Development (BDT) using Microsoft Visual Studio 2010 and SpecFlow, including an overview of BDT, different BDT methodologies, using Gherkin syntax to write scenarios, configuring SpecFlow tests in Visual Studio, and a live demo of SpecFlow.
Data Protection in a Connected World: Sovereignty and Cyber Securityanupriti
Delve into the critical intersection of data sovereignty and cyber security in this presentation. Explore unconventional cyber threat vectors and strategies to safeguard data integrity and sovereignty in an increasingly interconnected world. Gain insights into emerging threats and proactive defense measures essential for modern digital ecosystems.
In this follow-up session on knowledge and prompt engineering, we will explore structured prompting, chain of thought prompting, iterative prompting, prompt optimization, emotional language prompts, and the inclusion of user signals and industry-specific data to enhance LLM performance.
Join EIS Founder & CEO Seth Earley and special guest Nick Usborne, Copywriter, Trainer, and Speaker, as they delve into these methodologies to improve AI-driven knowledge processes for employees and customers alike.
Scaling Connections in PostgreSQL Postgres Bangalore(PGBLR) Meetup-2 - MydbopsMydbops
This presentation, delivered at the Postgres Bangalore (PGBLR) Meetup-2 on June 29th, 2024, dives deep into connection pooling for PostgreSQL databases. Aakash M, a PostgreSQL Tech Lead at Mydbops, explores the challenges of managing numerous connections and explains how connection pooling optimizes performance and resource utilization.
Key Takeaways:
* Understand why connection pooling is essential for high-traffic applications
* Explore various connection poolers available for PostgreSQL, including pgbouncer
* Learn the configuration options and functionalities of pgbouncer
* Discover best practices for monitoring and troubleshooting connection pooling setups
* Gain insights into real-world use cases and considerations for production environments
This presentation is ideal for:
* Database administrators (DBAs)
* Developers working with PostgreSQL
* DevOps engineers
* Anyone interested in optimizing PostgreSQL performance
Contact info@mydbops.com for PostgreSQL Managed, Consulting and Remote DBA Services
Implementations of Fused Deposition Modeling in real worldEmerging Tech
The presentation showcases the diverse real-world applications of Fused Deposition Modeling (FDM) across multiple industries:
1. **Manufacturing**: FDM is utilized in manufacturing for rapid prototyping, creating custom tools and fixtures, and producing functional end-use parts. Companies leverage its cost-effectiveness and flexibility to streamline production processes.
2. **Medical**: In the medical field, FDM is used to create patient-specific anatomical models, surgical guides, and prosthetics. Its ability to produce precise and biocompatible parts supports advancements in personalized healthcare solutions.
3. **Education**: FDM plays a crucial role in education by enabling students to learn about design and engineering through hands-on 3D printing projects. It promotes innovation and practical skill development in STEM disciplines.
4. **Science**: Researchers use FDM to prototype equipment for scientific experiments, build custom laboratory tools, and create models for visualization and testing purposes. It facilitates rapid iteration and customization in scientific endeavors.
5. **Automotive**: Automotive manufacturers employ FDM for prototyping vehicle components, tooling for assembly lines, and customized parts. It speeds up the design validation process and enhances efficiency in automotive engineering.
6. **Consumer Electronics**: FDM is utilized in consumer electronics for designing and prototyping product enclosures, casings, and internal components. It enables rapid iteration and customization to meet evolving consumer demands.
7. **Robotics**: Robotics engineers leverage FDM to prototype robot parts, create lightweight and durable components, and customize robot designs for specific applications. It supports innovation and optimization in robotic systems.
8. **Aerospace**: In aerospace, FDM is used to manufacture lightweight parts, complex geometries, and prototypes of aircraft components. It contributes to cost reduction, faster production cycles, and weight savings in aerospace engineering.
9. **Architecture**: Architects utilize FDM for creating detailed architectural models, prototypes of building components, and intricate designs. It aids in visualizing concepts, testing structural integrity, and communicating design ideas effectively.
Each industry example demonstrates how FDM enhances innovation, accelerates product development, and addresses specific challenges through advanced manufacturing capabilities.
this resume for sadika shaikh bca studentSadikaShaikh7
I am a dedicated BCA student with a strong foundation in web technologies, including PHP and MySQL. I have hands-on experience in Java and Python, and a solid understanding of data structures. My technical skills are complemented by my ability to learn quickly and adapt to new challenges in the ever-evolving field of computer science.
Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...Chris Swan
Have you noticed the OpenSSF Scorecard badges on the official Dart and Flutter repos? It's Google's way of showing that they care about security. Practices such as pinning dependencies, branch protection, required reviews, continuous integration tests etc. are measured to provide a score and accompanying badge.
You can do the same for your projects, and this presentation will show you how, with an emphasis on the unique challenges that come up when working with Dart and Flutter.
The session will provide a walkthrough of the steps involved in securing a first repository, and then what it takes to repeat that process across an organization with multiple repos. It will also look at the ongoing maintenance involved once scorecards have been implemented, and how aspects of that maintenance can be better automated to minimize toil.
Performance Budgets for the Real World by Tammy EvertsScyllaDB
Performance budgets have been around for more than ten years. Over those years, we’ve learned a lot about what works, what doesn’t, and what we need to improve. In this session, Tammy revisits old assumptions about performance budgets and offers some new best practices. Topics include:
• Understanding performance budgets vs. performance goals
• Aligning budgets with user experience
• Pros and cons of Core Web Vitals
• How to stay on top of your budgets to fight regressions
AI_dev Europe 2024 - From OpenAI to Opensource AIRaphaël Semeteys
Navigating Between Commercial Ownership and Collaborative Openness
This presentation explores the evolution of generative AI, highlighting the trajectories of various models such as GPT-4, and examining the dynamics between commercial interests and the ethics of open collaboration. We offer an in-depth analysis of the levels of openness of different language models, assessing various components and aspects, and exploring how the (de)centralization of computing power and technology could shape the future of AI research and development. Additionally, we explore concrete examples like LLaMA and its descendants, as well as other open and collaborative projects, which illustrate the diversity and creativity in the field, while navigating the complex waters of intellectual property and licensing.
UiPath Community Day Kraków: Devs4Devs ConferenceUiPathCommunity
We are honored to launch and host this event for our UiPath Polish Community, with the help of our partners - Proservartner!
We certainly hope we have managed to spike your interest in the subjects to be presented and the incredible networking opportunities at hand, too!
Check out our proposed agenda below 👇👇
08:30 ☕ Welcome coffee (30')
09:00 Opening note/ Intro to UiPath Community (10')
Cristina Vidu, Global Manager, Marketing Community @UiPath
Dawid Kot, Digital Transformation Lead @Proservartner
09:10 Cloud migration - Proservartner & DOVISTA case study (30')
Marcin Drozdowski, Automation CoE Manager @DOVISTA
Pawel Kamiński, RPA developer @DOVISTA
Mikolaj Zielinski, UiPath MVP, Senior Solutions Engineer @Proservartner
09:40 From bottlenecks to breakthroughs: Citizen Development in action (25')
Pawel Poplawski, Director, Improvement and Automation @McCormick & Company
Michał Cieślak, Senior Manager, Automation Programs @McCormick & Company
10:05 Next-level bots: API integration in UiPath Studio (30')
Mikolaj Zielinski, UiPath MVP, Senior Solutions Engineer @Proservartner
10:35 ☕ Coffee Break (15')
10:50 Document Understanding with my RPA Companion (45')
Ewa Gruszka, Enterprise Sales Specialist, AI & ML @UiPath
11:35 Power up your Robots: GenAI and GPT in REFramework (45')
Krzysztof Karaszewski, Global RPA Product Manager
12:20 🍕 Lunch Break (1hr)
13:20 From Concept to Quality: UiPath Test Suite for AI-powered Knowledge Bots (30')
Kamil Miśko, UiPath MVP, Senior RPA Developer @Zurich Insurance
13:50 Communications Mining - focus on AI capabilities (30')
Thomasz Wierzbicki, Business Analyst @Office Samurai
14:20 Polish MVP panel: Insights on MVP award achievements and career profiling
The Rise of Supernetwork Data Intensive ComputingLarry Smarr
Invited Remote Lecture to SC21
The International Conference for High Performance Computing, Networking, Storage, and Analysis
St. Louis, Missouri
November 18, 2021
1. introduction to android
testing
a hands-on approach
Copyright (C) 2011 Diego Torres Milano All rights reserved
2. diego torres milano
android system engineer
flextronics
http://dtmilano.blogspot.com
Copyright (C) 2011 Diego Torres Milano All rights reserved
3. “Never test the depth of
the water with both feet.”
-- Anonymous
Copyright (C) 2011 Diego Torres Milano All rights reserved
4. agenda
android testing background
test driven development
code coverage
continuous integration
behavior driven development
Copyright (C) 2011 Diego Torres Milano All rights reserved
5. operating systems
July 2011
Android
150M
iOS
222M
Copyright (C) 2011 Diego Torres Milano All rights reserved
6. android testing
background
Copyright (C) 2011 Diego Torres Milano All rights reserved
8. Why
?
Copyright (C) 2011 Diego Torres Milano All rights reserved
9. What Why
?
Copyright (C) 2011 Diego Torres Milano All rights reserved
10. What Why
When ?
Copyright (C) 2011 Diego Torres Milano All rights reserved
11. What Why
When
how
?
Copyright (C) 2011 Diego Torres Milano All rights reserved
12. types of test
tests
unit
functional
performance
integration
Copyright (C) 2011 Diego Torres Milano All rights reserved
13. types of test
unit
Copyright (C) 2011 Diego Torres Milano All rights reserved
14. types of test
by programmers for programmers
unit
Copyright (C) 2011 Diego Torres Milano All rights reserved
15. types of test
by programmers for programmers
unit
in a programming language
Copyright (C) 2011 Diego Torres Milano All rights reserved
16. types of test
by programmers for programmers
unit
in a programming language
JUnit is the de-facto standard
Copyright (C) 2011 Diego Torres Milano All rights reserved
17. types of test
by programmers for programmers
unit
in a programming language
JUnit is the de-facto standard
test objects in isolation
Copyright (C) 2011 Diego Torres Milano All rights reserved
18. types of test
by programmers for programmers
unit
in a programming language
JUnit is the de-facto standard
test objects in isolation
in a repeatable way
Copyright (C) 2011 Diego Torres Milano All rights reserved
19. types of test
by programmers for programmers
unit
in a programming language
JUnit is the de-facto standard
test objects in isolation
in a repeatable way
usually rely on mock objects
Copyright (C) 2011 Diego Torres Milano All rights reserved
20. types of test
tests
unit
functional
performance
integration
Copyright (C) 2011 Diego Torres Milano All rights reserved
21. types of test
functional
Copyright (C) 2011 Diego Torres Milano All rights reserved
22. types of test
by business & QA people functional
Copyright (C) 2011 Diego Torres Milano All rights reserved
23. types of test
by business & QA people functional
in a business domain language
Copyright (C) 2011 Diego Torres Milano All rights reserved
24. types of test
by business & QA people functional
in a business domain language
test completeness & correctness
Copyright (C) 2011 Diego Torres Milano All rights reserved
25. types of test
by business & QA people functional
in a business domain language
test completeness & correctness
BDD has gained some popularity
Copyright (C) 2011 Diego Torres Milano All rights reserved
26. types of test
by business & QA people functional
in a business domain language
test completeness & correctness
BDD has gained some popularity
FitNesse can help
Copyright (C) 2011 Diego Torres Milano All rights reserved
27. types of test
tests
unit
functional
performance
integration
Copyright (C) 2011 Diego Torres Milano All rights reserved
28. types of test
integration
Copyright (C) 2011 Diego Torres Milano All rights reserved
29. types of test
how components work together integration
Copyright (C) 2011 Diego Torres Milano All rights reserved
30. types of test
how components work together integration
modules have been unit tested
Copyright (C) 2011 Diego Torres Milano All rights reserved
31. types of test
how components work together integration
modules have been unit tested
android components need integration
with the system
Copyright (C) 2011 Diego Torres Milano All rights reserved
32. types of test
how components work together integration
modules have been unit tested
android components need integration
with the system
testing framework facilitates
integration
Copyright (C) 2011 Diego Torres Milano All rights reserved
33. types of test
tests
unit
functional
performance
integration
Copyright (C) 2011 Diego Torres Milano All rights reserved
35. types of test
measure performance in a
performance repeatable way
Copyright (C) 2011 Diego Torres Milano All rights reserved
36. types of test
measure performance in a
performance repeatable way
if cannot be measure cannot be
improved
Copyright (C) 2011 Diego Torres Milano All rights reserved
37. types of test
measure performance in a
performance repeatable way
if cannot be measure cannot be
improved
premature optimization does more
harm than good
Copyright (C) 2011 Diego Torres Milano All rights reserved
38. types of test
measure performance in a
performance repeatable way
if cannot be measure cannot be
improved
premature optimization does more
harm than good
measure-change-measure
Copyright (C) 2011 Diego Torres Milano All rights reserved
39. types of test
tests
unit
functional
performance
integration
Copyright (C) 2011 Diego Torres Milano All rights reserved
40. class diagram
Assert
<<iface>>
TestCase
Test
InstrumentationTestCase AndroidTestCase
ActivityInstrumentationTestCase2
ActivityUnitTestCase
Copyright (C) 2011 Diego Torres Milano All rights reserved
42. InstrumentationTestCase
instrumentation instantiated
before application
Copyright (C) 2011 Diego Torres Milano All rights reserved
43. InstrumentationTestCase
instrumentation instantiated
before application
allows for monitoring
interaction
Copyright (C) 2011 Diego Torres Milano All rights reserved
44. InstrumentationTestCase
instrumentation instantiated
before application
allows for monitoring
interaction
send keys and input events
Copyright (C) 2011 Diego Torres Milano All rights reserved
45. InstrumentationTestCase
instrumentation instantiated
before application
allows for monitoring
interaction
send keys and input events
manual lifecycle
Copyright (C) 2011 Diego Torres Milano All rights reserved
46. InstrumentationTestCase
instrumentation instantiated
before application
allows for monitoring
interaction
send keys and input events
manual lifecycle
direct or indirect base
class of other tests
Copyright (C) 2011 Diego Torres Milano All rights reserved
47. class diagram
Assert
<<iface>>
TestCase
Test
InstrumentationTestCase AndroidTestCase
ActivityInstrumentationTestCase2
ActivityUnitTestCase
Copyright (C) 2011 Diego Torres Milano All rights reserved
49. ActivityUnitTestCase
isolated testing of single
Activity
Copyright (C) 2011 Diego Torres Milano All rights reserved
50. ActivityUnitTestCase
isolated testing of single
Activity
minimal connection to
the system
Copyright (C) 2011 Diego Torres Milano All rights reserved
51. ActivityUnitTestCase
isolated testing of single
Activity
minimal connection to
the system
uses mocks for
dependencies
Copyright (C) 2011 Diego Torres Milano All rights reserved
52. ActivityUnitTestCase
isolated testing of single
Activity
minimal connection to
the system
uses mocks for
dependencies
some Activity methods
should not be called
Copyright (C) 2011 Diego Torres Milano All rights reserved
53. class diagram
Assert
<<iface>>
TestCase
Test
InstrumentationTestCase AndroidTestCase
ActivityInstrumentationTestCase2
ActivityUnitTestCase
Copyright (C) 2011 Diego Torres Milano All rights reserved
58. ActivityInstrumentationTestCase2
functional
testing of a single Activity
has access to Instrumentation
creates the AUT using system
infrastructure
custom intent can be provided
Copyright (C) 2011 Diego Torres Milano All rights reserved
59. class diagram
Assert
<<iface>>
TestCase
Test
InstrumentationTestCase AndroidTestCase
ActivityInstrumentationTestCase2
ActivityUnitTestCase
Copyright (C) 2011 Diego Torres Milano All rights reserved
61. access to Context AndroidTestCase
Copyright (C) 2011 Diego Torres Milano All rights reserved
62. access to Context AndroidTestCase
access to Resources
Copyright (C) 2011 Diego Torres Milano All rights reserved
63. access to Context AndroidTestCase
access to Resources
base class for Application, Provider
and Service test cases
Copyright (C) 2011 Diego Torres Milano All rights reserved
64. access to Context AndroidTestCase
access to Resources
base class for Application, Provider
and Service test cases
Context stored in mContext field
Copyright (C) 2011 Diego Torres Milano All rights reserved
65. access to Context AndroidTestCase
access to Resources
base class for Application, Provider
and Service test cases
Context stored in mContext field
can start more than one Activity
Copyright (C) 2011 Diego Torres Milano All rights reserved
66. class diagram
Assert
<<iface>>
TestCase
Test
InstrumentationTestCase AndroidTestCase
ActivityInstrumentationTestCase2
ActivityUnitTestCase
Copyright (C) 2011 Diego Torres Milano All rights reserved
68. test driven development advantages:
•the tests are written
one way or another
•developers take more
responsibility for the
quality of their work
Copyright (C) 2011 Diego Torres Milano All rights reserved
69. test driven development advantages:
•the tests are written
one way or another
•developers take more
responsibility for the
quality of their work
strategy of writing tests along development
Copyright (C) 2011 Diego Torres Milano All rights reserved
70. test driven development advantages:
•the tests are written
one way or another
•developers take more
responsibility for the
quality of their work
strategy of writing tests along development
test cases written prior to the code
Copyright (C) 2011 Diego Torres Milano All rights reserved
71. test driven development advantages:
•the tests are written
one way or another
•developers take more
responsibility for the
quality of their work
strategy of writing tests along development
test cases written prior to the code
single test added, then the code to satisfy it
Copyright (C) 2011 Diego Torres Milano All rights reserved
72. activity diagram
design decisions are
taken in single steps
and finally the code
write test satisfying the tests is
improved by
refactoring it
run
[fails]
code
[passes]
refactor
Copyright (C) 2011 Diego Torres Milano All rights reserved
73. temperature converter
Title
celsius
100
autoupdate
32
fahrenheit
keyboard
Copyright (C) 2011 Diego Torres Milano All rights reserved
75. requirements
converts between temperature
units
one temperature is entered and
the other is updated
error is displayed in the field
right aligned, 2 decimal digits
entry fields start empty
Copyright (C) 2011 Diego Torres Milano All rights reserved
77. understanding
requirements
to write a test you must understand the
requirement
Copyright (C) 2011 Diego Torres Milano All rights reserved
78. understanding
requirements
to write a test you must understand the
requirement
destination is quickly identified
Copyright (C) 2011 Diego Torres Milano All rights reserved
79. understanding
requirements
to write a test you must understand the
requirement
destination is quickly identified
if requirement change, changing the
corresponding test helps verify it
Copyright (C) 2011 Diego Torres Milano All rights reserved
80. github
$ mkdir myworkdir
$ cd myworkdir
$ git clone git@github.com:dtmilano/
TemperatureConverter.git
$ git clone git://github.com/dtmilano/
TemperatureConverterTests.git
Copyright (C) 2011 Diego Torres Milano All rights reserved
81. creating the
main project
TemperatureConverter uses
conventional settings
Copyright (C) 2011 Diego Torres Milano All rights reserved
82. creating the
main project
TemperatureConverter uses
conventional settings
Copyright (C) 2011 Diego Torres Milano All rights reserved
83. creating the test
project
Automatically selected values
for TemperatureConverterTest
project
Copyright (C) 2011 Diego Torres Milano All rights reserved
84. creating the test
case
Use:
ActivityInstrumentationTestCase2
as the base class
TemperatureConverterActivity as
the class under test
Copyright (C) 2011 Diego Torres Milano All rights reserved
85. warning
due to the
parameterized base
class
creating the test
case
Use:
ActivityInstrumentationTestCase2
as the base class
TemperatureConverterActivity as
the class under test
Copyright (C) 2011 Diego Torres Milano All rights reserved
86. constructor
/**
* Constructor
* @param name
*/
public TemperatureConverterActivityTests(String name) {
super(TemperatureConverterActivity.class);
setName(name);
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
87. fixture
protected void setUp(String name) throws Exception {
super.setUp();
mActivity = getActivity(); reference the
assertNotNull(mActivity); main package
mCelsius = (EditText)mActivity.findViewById(com...);
assertNotNull(mCelsius);
mFahrenheit = (EditText)mActivity.findViewById(com...);
assertNotNull(mFahrenheit);
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
89. ui tests: visibility
@SmallTest
public void testFieldsOnScreen() {
final View origin =
mActivity.getWindow().getDecorView();
ViewAsserts.assertOnScreen(origin, mCelsius);
ViewAsserts.assertOnScreen(origin, mFahrenheit);
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
90. ui tests: alignment
@SmallTest
public void testAlignment() {
! ! ViewAsserts.assertRightAligned(mCelsius,
mFahrenheit);
! ! ViewAsserts.assertLeftAligned(mCelsius,
mFahrenheit);
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
91. ui tests: initialization
@SmallTest
public void testFieldsShouldStartEmpty() {
! ! assertTrue("".equals(mCelsius.getText()
.toString()));
! ! assertTrue("".equals(mFahrenheit.getText()
.toString()));
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
92. ui tests: justification
@SmallTest
public void testJustification() {
! ! final int expected =
Gravity.RIGHT|Gravity.CENTER_VERTICAL;
! ! assertEquals(expected,
mCelsius.getGravity());
! ! assertEquals(expected,
mFahrenheit.getGravity());
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
93. running the tests
video plays on
click >>>
Copyright (C) 2011 Diego Torres Milano All rights reserved
94. running the tests
video plays on
click >>>
Copyright (C) 2011 Diego Torres Milano All rights reserved
95. gravity
add right and
center_vertical gravity
for celsius and
fahrenheit
Copyright (C) 2011 Diego Torres Milano All rights reserved
96. gravity
add right and
center_vertical gravity
for celsius and
fahrenheit
Copyright (C) 2011 Diego Torres Milano All rights reserved
97. running the tests
video plays on
click >>>
Copyright (C) 2011 Diego Torres Milano All rights reserved
98. running the tests
video plays on
click >>>
Copyright (C) 2011 Diego Torres Milano All rights reserved
99. temperature conversion
! @UiThreadTest
! public void testFahrenheitToCelsiusConversion() {
! ! mCelsius.clear();
! ! mFahrenheit.clear(); errors are
underlined in red
! ! final double f = 32.5;
! ! mFahrenheit.requestFocus();
! ! mFahrenheit.setNumber(f);
! ! mCelsius.requestFocus();
! ! final double expected =
TemperatureConverter.fahrenheitToCelsius(f);
! ! final double actual = mCelsius.getNumber();
! ! final double delta = Math.abs(expected - actual);
! ! assertTrue(delta < 0.005);
! }
Copyright (C) 2011 Diego Torres Milano All rights reserved
100. temperature conversionrun in the ui
! @UiThreadTest thread
! public void testFahrenheitToCelsiusConversion() {
! ! mCelsius.clear();
! ! mFahrenheit.clear(); errors are
underlined in red
! ! final double f = 32.5;
! ! mFahrenheit.requestFocus();
! ! mFahrenheit.setNumber(f);
! ! mCelsius.requestFocus();
! ! final double expected =
TemperatureConverter.fahrenheitToCelsius(f);
! ! final double actual = mCelsius.getNumber();
! ! final double delta = Math.abs(expected - actual);
! ! assertTrue(delta < 0.005);
! }
Copyright (C) 2011 Diego Torres Milano All rights reserved
101. temperature conversionrun in the ui
! @UiThreadTest thread
! public void testFahrenheitToCelsiusConversion() {
specialized
class
! ! mCelsius.clear();
! ! mFahrenheit.clear(); errors are
underlined in red
! ! final double f = 32.5;
! ! mFahrenheit.requestFocus();
! ! mFahrenheit.setNumber(f);
! ! mCelsius.requestFocus();
! ! final double expected =
TemperatureConverter.fahrenheitToCelsius(f);
! ! final double actual = mCelsius.getNumber();
! ! final double delta = Math.abs(expected - actual);
! ! assertTrue(delta < 0.005);
! }
Copyright (C) 2011 Diego Torres Milano All rights reserved
102. temperature conversion run in the ui
! @UiThreadTest thread
! public void testFahrenheitToCelsiusConversion() {
specialized
class
! ! mCelsius.clear();
! ! mFahrenheit.clear(); errors are
underlined in red
! ! final double f = 32.5;
! ! mFahrenheit.requestFocus();
! ! mFahrenheit.setNumber(f); converter
! ! mCelsius.requestFocus(); helper
! ! final double expected =
TemperatureConverter.fahrenheitToCelsius(f);
! ! final double actual = mCelsius.getNumber();
! ! final double delta = Math.abs(expected - actual);
! ! assertTrue(delta < 0.005);
! }
Copyright (C) 2011 Diego Torres Milano All rights reserved
103. EditNumber class
EditNumber class
extends EditText
Copyright (C) 2011 Diego Torres Milano All rights reserved
104. TemperatureCon
verter
TemperatureConverter
is a helper class
Copyright (C) 2011 Diego Torres Milano All rights reserved
105. exception
java.lang.ClassCastException:
android.widget.EditText at
com.example.i2at.tc.test.
TemperatureConverterActivityTests.setUp
(TemperatureConverterActivityTests.java: 44)
Copyright (C) 2011 Diego Torres Milano All rights reserved
106. exception
java.lang.ClassCastException:
android.widget.EditText at
com.example.i2at.tc.test.
TemperatureConverterActivityTests.setUp
(TemperatureConverterActivityTests.java: 44)
44:!! mCelsius = (EditNumber)
mActivity.findViewById(
com.example.i2at.tc.R.id.celsius);
Copyright (C) 2011 Diego Torres Milano All rights reserved
107. layout
<com.example.i2at.tc.EditNumber
android:layout_height="wrap_content"
! ! android:layout_width="match_parent"
android:inputType="numberDecimal"
! ! android:id="@+id/celsius"
android:gravity="right|center_vertical">
! ! <requestFocus />
</com.example.i2at.tc.EditNumber>
Copyright (C) 2011 Diego Torres Milano All rights reserved
108. running the tests
Copyright (C) 2011 Diego Torres Milano All rights reserved
109. running the tests
what?
Copyright (C) 2011 Diego Torres Milano All rights reserved
110. celsius to fahrenheit
Fahrenheit
150
112.5
75
37.5
0
-37.5
-75
-40 -30 -20 -10 0 10 20 30 40
Celsius
Copyright (C) 2011 Diego Torres Milano All rights reserved
111. celsius to fahrenheit
Fahrenheit
150
112.5
75
f = 9/5 * c + 32
37.5
0
c = (f-32) * 5/9
-37.5
-75
-40 -30 -20 -10 0 10 20 30 40
Celsius
Copyright (C) 2011 Diego Torres Milano All rights reserved
112. converter
public class TemperatureConverter {
! public static double fahrenheitToCelsius(double f) {
/ TODO Auto-generated method stub
/
! ! return 0;
! }
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
113. TemperatureConv
erterTests
Test case as base class
create method stubs
TemperatureConverter as
CUT
Copyright (C) 2011 Diego Torres Milano All rights reserved
114. method stubs
select the methods you want
stubs created for
Copyright (C) 2011 Diego Torres Milano All rights reserved
115. conversion test
public void testFahrenheitToCelsius() {
! ! for (double c: sConversionTableDouble.keySet()) {
! ! ! final double f = sConversionTableDouble.get(c);
! ! ! final double ca =
TemperatureConverter.fahrenheitToCelsius(f);
! ! ! final double delta = Math.abs(ca - c);
! ! ! assertTrue(delta < 0.005);
! ! }
! }
Copyright (C) 2011 Diego Torres Milano All rights reserved
118. run the tests
this
assertion fails
Copyright (C) 2011 Diego Torres Milano All rights reserved
119. creating test
case
use AndroidTestCase as base
class
use EditNumber as CUT
Copyright (C) 2011 Diego Torres Milano All rights reserved
120. method stubs
select the Context constructor
select other methods
Copyright (C) 2011 Diego Torres Milano All rights reserved
121. test
public final void testClear() {
! ! final String value = "123.45";
! ! mEditNumber.setText(value);
! ! mEditNumber.clear();
! ! final String expected = "";
! ! final String actual =
mEditNumber.getText().toString();
! ! assertEquals(expected, actual);
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
122. implementation
public class EditNumber extends EditText {
/ ...
/
! public void clear() {
! ! setText("");
! }
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
123. test
public final void testSetNumber() {
! ! final double d = 123.45;
! ! mEditNumber.setNumber(d);
! ! final String expected = Double.toString(d);
! ! final String actual =
mEditNumber.getText().toString();
! ! assertEquals(expected, actual);
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
124. test
public final void testGetNumber() {
! ! final double expected = 123.45;
! ! mEditNumber.setNumber(expected);
! ! final double actual =
mEditNumber.getNumber();
! ! assertEquals(expected, actual);
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
125. implementation
public class EditNumber extends EditText {
/ ...
/
! public void getNumber() {
final String s = getText().toString();
if ( "".equals(s) ) {
return Double.NaN;
}
! ! return Double.valueOf(s);
! }
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
126. run the tests NO video
Copyright (C) 2011 Diego Torres Milano All rights reserved
127. what’s the problem ?
Copyright (C) 2011 Diego Torres Milano All rights reserved
128. what’s the problem ?
clear() works
requestFocus() works
setNumber() works
fahrenheitToCelsius() works
getNumber() works
so ?
Copyright (C) 2011 Diego Torres Milano All rights reserved
129. temperature converter
Title
celsius
100
32
fahrenheit
keyboard
Copyright (C) 2011 Diego Torres Milano All rights reserved
130. temperature converter
Title
celsius
100
autoupdate
32
fahrenheit
keyboard
Copyright (C) 2011 Diego Torres Milano All rights reserved
131. TemperatureChan
geWatcher
create it as an inner class
implements TextWatcher
inherited abstract methods
create 2 fields mSource &
mDest
Copyright (C) 2011 Diego Torres Milano All rights reserved
132. generate
constructor
use the fields
omit call to super()
Copyright (C) 2011 Diego Torres Milano All rights reserved
133. the watcher
public abstract class TemperatureChangeWatcher
implements TextWatcher {
! ! private EditNumber mSource;
! ! private EditNumber mDest;
! !
! ! public TemperatureChangeWatcher(
EditNumber source, EditNumber dest) {
! ! ! this.mSource = source;
! ! ! this.mDest = dest;
! ! }
/ ...
/
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
134. on text changed
@Override
public void onTextChanged(CharSequence s, int start, int before, int count) {
! if ( !mDest.hasWindowFocus() || mDest.hasFocus() || s == null ) return;
! final String str = s.toString();
! if ( "".equals(str) ) {
! ! mDest.setText(""); return;
! }
! try {
! ! final double result = convert(Double.parseDouble(str));
! ! mDest.setNumber(result);
! }
! catch (NumberFormatException e) {
! ! / WARNING: this is thrown while a number is entered, for example just a '-'
/
! }
! catch (Exception e) {
! ! mSource.setError("ERROR: " + e.getLocalizedMessage());
! }
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
135. on text changed
@Override
public void onTextChanged(CharSequence s, int start, int before, int count) {
! if ( !mDest.hasWindowFocus() || mDest.hasFocus() || s == null ) return;
! final String str = s.toString();
! if ( "".equals(str) ) {
! ! mDest.setText(""); return;
we should
! }
define it
! try {
! ! final double result = convert(Double.parseDouble(str));
! ! mDest.setNumber(result);
! }
! catch (NumberFormatException e) {
! ! / WARNING: this is thrown while a number is entered, for example just a '-'
/
! }
! catch (Exception e) {
! ! mSource.setError("ERROR: " + e.getLocalizedMessage());
! }
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
136. abstract convert method
public abstract class TemperatureChangeWatcher
implements TextWatcher {
//...
protected abstract double convert(double temp);
//...
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
137. find views
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
mCelsius =
(EditNumber) findViewById(R.id.celsius);
mFahrenheit =
(EditNumber) findViewById(R.id.fahrenheit);
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
138. add change listeners
@Override
public void onCreate(Bundle savedInstanceState) {
/ ...
/
mCelsius.addTextChangedListener(
we should
new TemperatureChangeWatcher(mCelsius, mFahrenheit) {
create it
! ! ! @Override protected double convert(double temp) {
! ! ! ! return TemperatureConverter.celsiusToFahrenheit(temp);
! ! ! }!
});
mFahrenheit.addTextChangedListener(
new TemperatureChangeWatcher(mFahrenheit, mCelsius) {
! ! ! @Override protected double convert(double temp) {
! ! ! ! return TemperatureConverter.fahrenheitToCelsius(temp);
! ! ! }
});
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
139. add conversion
public class TemperatureConverter {
! public static double fahrenheitToCelsius(double f) {
! ! return (f-32) * 5/9.0;
! }
! public static double celsiusToFahrenheit(double c) {
! ! / TODO Auto-generated method stub
/
! ! return 0;
! }
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
140. adding test
public class TemperatureConverterTests extends TestCase {
/ ...
/
! /**
! * Test method for {@link TemperatureConverter#fahrenheitToCelsius(double)}.
! */
! public void testCelsiusToFahrenheit() {
! ! for (double c: sConversionTableDouble.keySet()) {
! ! ! final double f = sConversionTableDouble.get(c);
! ! ! final double fa = TemperatureConverter.celsiusToFahrenheit(c);
! ! ! final double delta = Math.abs(fa - f);
! ! ! assertTrue("delta=" + delta + " for f=" + f + " fa=" + fa, delta < 0.005);
! ! }
! }
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
141. running the tests
Copyright (C) 2011 Diego Torres Milano All rights reserved
142. implementing conversion
public class TemperatureConverter {
! public static double fahrenheitToCelsius(double f) {
! ! return (f-32) * 5/9.0;
! }
! public static double celsiusToFahrenheit(double c) {
! ! return 9/5.0 * c + 32;
! }
}
Copyright (C) 2011 Diego Torres Milano All rights reserved
143. running the tests
Copyright (C) 2011 Diego Torres Milano All rights reserved
146. code coverage
measures the amount of source code tested
Copyright (C) 2011 Diego Torres Milano All rights reserved
147. code coverage
measures the amount of source code tested
android relies on emma (http://emma.sf.net)
Copyright (C) 2011 Diego Torres Milano All rights reserved
148. code coverage
measures the amount of source code tested
android relies on emma (http://emma.sf.net)
supported coverage types:
class
method
line
block
Copyright (C) 2011 Diego Torres Milano All rights reserved
152. coverage report
overall coverage summary
overall stats summary
coverage breakdown by package
Copyright (C) 2011 Diego Torres Milano All rights reserved
153. building with ant
disable project’s Build Automatically in Eclipse
convert project to ant
$ android update project --path $PWD --name
TemperatureConverter --target android-10
$ android update test-project --main ../
TemperatureConverter --path $PWD
Copyright (C) 2011 Diego Torres Milano All rights reserved
154. run
configuration coverage
run build.xml as Ant build...
use coverage target
Copyright (C) 2011 Diego Torres Milano All rights reserved
155. ant 1.8
specify ant 1.8 home
Ant home...
Copyright (C) 2011 Diego Torres Milano All rights reserved
156. coverage
run build.xml coverage
coverage analysis report is generated
get coverage file
$ adb pull /data/data/com.example.i2at.tc/files/
coverage.ec coverage.ec
Copyright (C) 2011 Diego Torres Milano All rights reserved
170. requirements
converts between temperature
units
one temperature is entered and
the other is updated
error is displayed in the field
right aligned, 2 decimal digits
entry fields start empty
Copyright (C) 2011 Diego Torres Milano All rights reserved
172. continuous integration
agile technique for software engineering
received broad adoption in recent years
prevents “integration hell”
integrate changes frequently
Copyright (C) 2011 Diego Torres Milano All rights reserved
181. build dependency
these are the
TemperatureConverterTest
project options. This depends on
TemperatureConverter.
Copyright (C) 2011 Diego Torres Milano All rights reserved
185. xml test results
download xmlinstrumentationtestrunner.jar
replace instrumentation by
android:name="com.neenbedankt.android.test.
XMLInstrumentationTestRunner"
customize build.xml
Copyright (C) 2011 Diego Torres Milano All rights reserved
189. behavior driven
development
evolution of Test Driven Development
inclusion of business participant
common vocabulary
based on Neuro Linguistics Programming
Copyright (C) 2011 Diego Torres Milano All rights reserved
195. android application
testing guide
Copyright (C) 2011 Diego Torres Milano All rights reserved
196. android application
testing guide
Apply testing techniques and tools
• Learn the nuances of Unit and
Functional testing
• Understand different development
methodologies such as TDD and BDD
• Apply Continuous Integration
• Improve applications using
performance tests
• Expose your application to a wide
range of conditions
Copyright (C) 2011 Diego Torres Milano All rights reserved
Google CEO Larry Page&#x2019;s blog post announcing the news: Android now has a total of over 150 million activated devices worldwide. That number is up from 130 million handsets only a month ago. And they continue to sell at a rate of over 550,000 new activations a day (this stat had been previously announced). To add some context, Apple announced last month that it&#x2019;s sold 222 million iOS devices to date, including the iPod Touch, iPad, and iPhone.\n
We will be reviewing the main concepts behind testing and the techniques, frameworks, and tools available to deploy your testing strategy on Android.\nInitially, when Android was introduced by the end of 2007, there was very little support for testing on the platform, but with the latests SDK versions a complete test framework was introduced.\n\n
why: because bugs severely affect projects, killing them early saves project resources, also to grasp requirements\nwhat: the more you cover higher the expectations of finding bugs, coverage analysis helps\nwhen: the sooner the better, TDD, an agile component, helps in this area and forces you to face bugs earlier\nhow: applying the techniques and tools we will be revealing soon\n
why: because bugs severely affect projects, killing them early saves project resources, also to grasp requirements\nwhat: the more you cover higher the expectations of finding bugs, coverage analysis helps\nwhen: the sooner the better, TDD, an agile component, helps in this area and forces you to face bugs earlier\nhow: applying the techniques and tools we will be revealing soon\n
why: because bugs severely affect projects, killing them early saves project resources, also to grasp requirements\nwhat: the more you cover higher the expectations of finding bugs, coverage analysis helps\nwhen: the sooner the better, TDD, an agile component, helps in this area and forces you to face bugs earlier\nhow: applying the techniques and tools we will be revealing soon\n
why: because bugs severely affect projects, killing them early saves project resources, also to grasp requirements\nwhat: the more you cover higher the expectations of finding bugs, coverage analysis helps\nwhen: the sooner the better, TDD, an agile component, helps in this area and forces you to face bugs earlier\nhow: applying the techniques and tools we will be revealing soon\n
Testing can be implemented at any time in the development process. However, we will be promoting testing at an early stage of the development effort, even before the full set of requirements have been defined and the coding process has been started.\nThere are several types of test available depending on the object being tested. Regardless of its type, a test should verify a condition and return the result of this evaluation as a single Boolean value indicating success or failure.\n\n
Unit tests are software tests written by programmers for programmers in a programming language and they should isolate the component under test and be able to test it in a repeatable way.\n\n
Unit tests are software tests written by programmers for programmers in a programming language and they should isolate the component under test and be able to test it in a repeatable way.\n\n
Unit tests are software tests written by programmers for programmers in a programming language and they should isolate the component under test and be able to test it in a repeatable way.\n\n
Unit tests are software tests written by programmers for programmers in a programming language and they should isolate the component under test and be able to test it in a repeatable way.\n\n
Unit tests are software tests written by programmers for programmers in a programming language and they should isolate the component under test and be able to test it in a repeatable way.\n\n
Unit tests are software tests written by programmers for programmers in a programming language and they should isolate the component under test and be able to test it in a repeatable way.\n\n
Android (up to Android 2.3 Gingerbread) uses JUnit 3. This version doesn't use annotations and uses introspection to detect the tests.\n\n
In agile software development, functional or acceptance tests are usually created by business and Quality Assurance (QA) people and expressed in a business domain language. These are high level tests to test the completeness and correctness of a user requirement or feature.\nWe will be introducing FitNesse, a framework that can be integrated \n\n
In agile software development, functional or acceptance tests are usually created by business and Quality Assurance (QA) people and expressed in a business domain language. These are high level tests to test the completeness and correctness of a user requirement or feature.\nWe will be introducing FitNesse, a framework that can be integrated \n\n
In agile software development, functional or acceptance tests are usually created by business and Quality Assurance (QA) people and expressed in a business domain language. These are high level tests to test the completeness and correctness of a user requirement or feature.\nWe will be introducing FitNesse, a framework that can be integrated \n\n
In agile software development, functional or acceptance tests are usually created by business and Quality Assurance (QA) people and expressed in a business domain language. These are high level tests to test the completeness and correctness of a user requirement or feature.\nWe will be introducing FitNesse, a framework that can be integrated \n\n
In agile software development, functional or acceptance tests are usually created by business and Quality Assurance (QA) people and expressed in a business domain language. These are high level tests to test the completeness and correctness of a user requirement or feature.\nWe will be introducing FitNesse, a framework that can be integrated \n\n
\n
Integration tests are designed to test the way individual components work jointly. Modules that have been unit tested independently are now combined together to test the integration.\nUsually Android Activities require some integration with the system infrastructure to be able to run. They need the Activity lifecycle provided by the ActivityManager, and access to resources, filesystem, and databases.\n\n
Integration tests are designed to test the way individual components work jointly. Modules that have been unit tested independently are now combined together to test the integration.\nUsually Android Activities require some integration with the system infrastructure to be able to run. They need the Activity lifecycle provided by the ActivityManager, and access to resources, filesystem, and databases.\n\n
Integration tests are designed to test the way individual components work jointly. Modules that have been unit tested independently are now combined together to test the integration.\nUsually Android Activities require some integration with the system infrastructure to be able to run. They need the Activity lifecycle provided by the ActivityManager, and access to resources, filesystem, and databases.\n\n
Integration tests are designed to test the way individual components work jointly. Modules that have been unit tested independently are now combined together to test the integration.\nUsually Android Activities require some integration with the system infrastructure to be able to run. They need the Activity lifecycle provided by the ActivityManager, and access to resources, filesystem, and databases.\n\n
\n
And finally, Performance tests measure performance characteristics of the components in a repeatable way.\nAs is widely known, premature optimization does more harm than good, so it is better to clearly understand the impact of your changes on the overall performance.\n\n
And finally, Performance tests measure performance characteristics of the components in a repeatable way.\nAs is widely known, premature optimization does more harm than good, so it is better to clearly understand the impact of your changes on the overall performance.\n\n
And finally, Performance tests measure performance characteristics of the components in a repeatable way.\nAs is widely known, premature optimization does more harm than good, so it is better to clearly understand the impact of your changes on the overall performance.\n\n
And finally, Performance tests measure performance characteristics of the components in a repeatable way.\nAs is widely known, premature optimization does more harm than good, so it is better to clearly understand the impact of your changes on the overall performance.\n\n
Android provides a very advanced testing framework extending the industry standard JUnit with specific features suitable for implementing all of the testing strategies and types we mentioned before.\n\n
\n
Yellow: junit Green: android\n\n
The instrumentation framework is the foundation of the testing framework. Instrumentation controls the application under test and permits the injection of mock components required by the application to run. For example, you can create mock Contexts before the application starts and let the application use them.\nHas launchActivity and launchActivityWithIntent utility methods.\n
The instrumentation framework is the foundation of the testing framework. Instrumentation controls the application under test and permits the injection of mock components required by the application to run. For example, you can create mock Contexts before the application starts and let the application use them.\nHas launchActivity and launchActivityWithIntent utility methods.\n
The instrumentation framework is the foundation of the testing framework. Instrumentation controls the application under test and permits the injection of mock components required by the application to run. For example, you can create mock Contexts before the application starts and let the application use them.\nHas launchActivity and launchActivityWithIntent utility methods.\n
The instrumentation framework is the foundation of the testing framework. Instrumentation controls the application under test and permits the injection of mock components required by the application to run. For example, you can create mock Contexts before the application starts and let the application use them.\nHas launchActivity and launchActivityWithIntent utility methods.\n
The instrumentation framework is the foundation of the testing framework. Instrumentation controls the application under test and permits the injection of mock components required by the application to run. For example, you can create mock Contexts before the application starts and let the application use them.\nHas launchActivity and launchActivityWithIntent utility methods.\n
All interaction of the application with the surrounding environment can be controlled using this approach. You can also isolate your application in a restricted environment to be able to predict the results, forcing the values returned by some methods or mocking persistent and unchanged data for ContentProvider, databases, or even the filesystem content.\n
The following methods should not be called in this configuration - most of them will throw exceptions:\nstartActivityIfNeeded(), getCallingActivity(), getTaskId(), moveTaskToBack()\n\n
The following methods should not be called in this configuration - most of them will throw exceptions:\nstartActivityIfNeeded(), getCallingActivity(), getTaskId(), moveTaskToBack()\n\n
The following methods should not be called in this configuration - most of them will throw exceptions:\nstartActivityIfNeeded(), getCallingActivity(), getTaskId(), moveTaskToBack()\n\n
The following methods should not be called in this configuration - most of them will throw exceptions:\nstartActivityIfNeeded(), getCallingActivity(), getTaskId(), moveTaskToBack()\n\n
\n
\n
\n
\n
\n
\n
This class can be used as a base class for general purpose Android test cases.\nUse this class when you need access to an Activity Context like Resources, databases, or files in the filesystem. Context is stored as a field in this class conveniently named mContext and can be used inside the tests if needed.\nTests based on this class can start more than one Activity using Context.startActivity().\n\n
This class can be used as a base class for general purpose Android test cases.\nUse this class when you need access to an Activity Context like Resources, databases, or files in the filesystem. Context is stored as a field in this class conveniently named mContext and can be used inside the tests if needed.\nTests based on this class can start more than one Activity using Context.startActivity().\n\n
This class can be used as a base class for general purpose Android test cases.\nUse this class when you need access to an Activity Context like Resources, databases, or files in the filesystem. Context is stored as a field in this class conveniently named mContext and can be used inside the tests if needed.\nTests based on this class can start more than one Activity using Context.startActivity().\n\n
This class can be used as a base class for general purpose Android test cases.\nUse this class when you need access to an Activity Context like Resources, databases, or files in the filesystem. Context is stored as a field in this class conveniently named mContext and can be used inside the tests if needed.\nTests based on this class can start more than one Activity using Context.startActivity().\n\n
This class can be used as a base class for general purpose Android test cases.\nUse this class when you need access to an Activity Context like Resources, databases, or files in the filesystem. Context is stored as a field in this class conveniently named mContext and can be used inside the tests if needed.\nTests based on this class can start more than one Activity using Context.startActivity().\n\n
\n
\n
Briefly, Test Driven Development is the strategy of writing tests along the development process. These test cases are written in advance of the code that is supposed to satisfy them.\nThis contrasts with other approaches to the development process where the tests are written at the end when all the coding has been done.\n\n
Briefly, Test Driven Development is the strategy of writing tests along the development process. These test cases are written in advance of the code that is supposed to satisfy them.\nThis contrasts with other approaches to the development process where the tests are written at the end when all the coding has been done.\n\n
Briefly, Test Driven Development is the strategy of writing tests along the development process. These test cases are written in advance of the code that is supposed to satisfy them.\nThis contrasts with other approaches to the development process where the tests are written at the end when all the coding has been done.\n\n
Design decisions are taken in single steps and finally the code satisfying the tests is improved by refactoring it.\nWe start our development process with writing a test case. This apparently simple process will put some machinery to work inside our heads.\n\n
\n
\n
\n
\n
\n
\n
The main advantage I've seen so far is that you focus your destination quickly and is much difficult to divert implementing options in your software that will never be used.\nTest Driven Development could not be indiscriminately applied to any project. I think that, as well as any other technique you should use your judgment and expertise to recognize where it can be applied.\n\n\n
The main advantage I've seen so far is that you focus your destination quickly and is much difficult to divert implementing options in your software that will never be used.\nTest Driven Development could not be indiscriminately applied to any project. I think that, as well as any other technique you should use your judgment and expertise to recognize where it can be applied.\n\n\n
The main advantage I've seen so far is that you focus your destination quickly and is much difficult to divert implementing options in your software that will never be used.\nTest Driven Development could not be indiscriminately applied to any project. I think that, as well as any other technique you should use your judgment and expertise to recognize where it can be applied.\n\n\n
git read-only access.\nDon&#x2019;t forget to adapt local.properties.template to suit your environment needs if using ant.\nImport into Eclipse.\n
Our examples will revolve around an extremely simple Android sample project. It doesn't try to show all the fancy Android features but focuses on testing and gradually building the application from the test, applying the concepts learned before.\n
The creation of the test project is displayed in this screenshot. All values will be selected for you based on your previous entries.\n\n
Proceed with creating the first test by selecting the main test package name com.example.aatg.tc.test in Eclipse's Package Explorer, and then right-click on it. Select New | JUnit Test Case.\nJUnit 3 is the version supported by Android. Always use this option.\n
We now notice that our automatically generated class has some errors we need to fix before running. Otherwise the errors will prevent the test from compiling.\nFirst we should add the missing imports, using the shortcut Shift+Ctrl+O.\nSecond, the problem we need to fix is the no argument constructor.\n\n
We can start creating our test fixture (well known state defined as a baseline) by populating the setUp method with the elements we need in our tests. Almost unavoidable, in this case, is the use of the Activity under test, so let's prepare for the situation and add it to the fixture.\nThe ActivityInstrumentationTestCase2.getActivity() method has a side effect. If the Activity under test is not running, it is started.\n\n
\n
\n
\n
\n
\n
Video plays on click >>>\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
We define convert as an abstract method, to invoke the corresponding convert method depending on the conversion needed\n
We will be creating anonymous classes when we assign the watchers\n
\n
\n
\n
\n
\n
\n
\n
\n
Code coverage is a measure used in software testing that describes the amount of source code that was actually tested by the test suite and to what degree following some criteria.\n\n
Code coverage is a measure used in software testing that describes the amount of source code that was actually tested by the test suite and to what degree following some criteria.\n\n
Code coverage is a measure used in software testing that describes the amount of source code that was actually tested by the test suite and to what degree following some criteria.\n\n
overall summary: the summary for all classes\noverall stats summary: the statistics of the coverage (i.e. how many packages)\ncoverage breakdown: coverage for particular packages\n
overall summary: the summary for all classes\noverall stats summary: the statistics of the coverage (i.e. how many packages)\ncoverage breakdown: coverage for particular packages\n
overall summary: the summary for all classes\noverall stats summary: the statistics of the coverage (i.e. how many packages)\ncoverage breakdown: coverage for particular packages\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
The original article was written by Martin Fowler back in 2000, and describes the experience of putting together Continuous Integration on a large software project.\nContinuous Integration has received a broad adoption in recent years, and a proliferation of commercial tools and Open Source projects is a clear demonstration of its success.\n\n
Continuous Integration is one agile technique for software engineering that aims to improve the software quality and to reduce the time taken to integrate changes by continuously applying integration and testing frequently, opposed to the more traditional approach of integrating and testing by the end of the development cycle.\n\n
The most common practice is to trigger the build process after every commit to the source code repository, this practice also implies other requirements, beside the source code being maintained by a Version Control System.\nBuilds should be automated by running a single command.\nThe build should be self tested,\n