Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletter Hub
Free Learning
Arrow right icon
Learning Android Application Testing
Learning Android Application Testing

Learning Android Application Testing: Improve your Android applications through intensive testing and debugging

eBook
$9.99 $43.99
Paperback
$54.99
Subscription
Free Trial
Renews at $19.99p/m

What do you get with Print?

Product feature icon Instant access to your digital eBook copy whilst your Print order is Shipped
Product feature icon Paperback book shipped to your preferred address
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
OR
Modal Close icon
Payment Processing...
tick Completed

Shipping Address

Billing Address

Shipping Methods
Table of content icon View table of contents Preview book icon Preview Book

Learning Android Application Testing

Chapter 2. Understanding Testing with the Android SDK

We now know how to create tests inside an Android project and how to run these tests. It is now time to start digging a bit deeper to recognize the building blocks available to create more useful tests.

In this second chapter, we will be covering the following topics:

  • Common assertions
  • View assertions
  • Other assertion types
  • Helpers to test User Interfaces
  • Mock objects
  • Instrumentation
  • TestCase class hierarchies
  • Using external libraries

We will be analyzing these components and showing examples of their use when applicable. The examples in this chapter are intentionally split from the original Android project that contains them. This is done to let you concentrate and focus only on the subject being presented, though the complete examples in a single project can be downloaded as explained later. Right now, we are interested in the trees and not the forest.

Along with the examples presented, we will be identifying reusable common patterns...

The demonstration application

A very simple application has been created to demonstrate the use of some of the tests in this chapter. The source for the application can be downloaded from the Packt website at http://packtpub.com

The following screenshot shows this application running:

The demonstration application

When reading the explanation of the tests in this chapter, at any point, you can refer to the demo application that is provided in order to see the test in action. The previous simple application has a clickable link, text input, click on a button and a defined layout UI, we can test these one by one.

Assertions in depth

Assertions are methods that check for a condition that can be evaluated. If the condition is not met, the assertion method will throw an exception, thereby aborting the execution of the test.

The JUnit API includes the class Assert. This is the base class of all the TestCase classes that hold several assertion methods useful for writing tests. These inherited methods test for a variety of conditions and are overloaded to support different parameter types. They can be grouped together in the following different sets, depending on the condition checked, for example:

  • assertEquals
  • assertTrue
  • assertFalse
  • assertNull
  • assertNotNull
  • assertSame
  • assertNotSame
  • fail

The condition tested is pretty obvious and is easily identifiable by the method name. Perhaps the ones that deserve some attention are assertEquals() and assertSame(). The former, when used on objects, asserts that both objects passed as parameters are equally calling the objects' equals() method. The latter asserts that both...

View assertions

The assertions introduced earlier handle a variety of types as parameters, but they are only intended to test simple conditions or simple objects.

For example, we have asertEquals(short expected, short actual) to test short values, assertEquals(int expected, int actual) to test integer values, assertEquals(Object expected, Object expected) to test any Object instance, and so on.

Usually, while testing user interfaces in Android, you will face the problem of more sophisticated methods, which are mainly related with Views. In this respect, Android provides a class with plenty of assertions in android.test.ViewAsserts (see http://developer.android.com/reference/android/test/ViewAsserts.html for more details), which test relationships between Views and their absolute and relative positions on the screen.

These methods are also overloaded to provide different conditions. Among the assertions, we can find the following:

  • assertBaselineAligned: This asserts that two Views are aligned...

Even more assertions

If the assertions that are reviewed previously do not seem to be enough for your tests' needs, there is still another class included in the Android framework that covers other cases. This class is MoreAsserts (http://developer.android.com/reference/android/test/MoreAsserts.html).

These methods are also overloaded to support different parameter types. Among the assertions, we can find the following:

  • assertAssignableFrom: This asserts that an object is assignable to a class.
  • assertContainsRegex: This asserts that an expected Regex matches any substring of the specified String. It fails with the specified message if it does not.
  • assertContainsInAnyOrder: This asserts that the specified Iterable contains precisely the elements expected, but in any order.
  • assertContainsInOrder: This asserts that the specified Iterable contains precisely the elements expected, but in the same order.
  • assertEmpty: This asserts that an Iterable is empty.
  • assertEquals: This is for some Collections...

The TouchUtils class

Sometimes, when testing UIs, it is helpful to simulate different kinds of touch events. These touch events can be generated in many different ways, but probably android.test.TouchUtils is the simplest to use. This class provides reusable methods to generate touch events in test cases that are derived from InstrumentationTestCase.

The featured methods allow a simulated interaction with the UI under test. The TouchUtils class provides the infrastructure to inject the events using the correct UI or main thread, so no special handling is needed, and you don't need to annotate the test using @UIThreadTest.

TouchUtils supports the following:

  • Clicking on a View and releasing it
  • Tapping on a View (touching it and quickly releasing)
  • Long-clicking on a View
  • Dragging the screen
  • Dragging Views

The following test represents a typical usage of TouchUtils:

    public void testListScrolling() {
        listView.scrollTo(0, 0);

        TouchUtils.dragQuarterScreenUp(this, activity); 
...

Mock objects

We have seen the mock objects provided by the Android testing framework in Chapter 1, Getting Started with Testing, and evaluated the concerns about not using real objects to isolate our tests from the surrounding environment.

The next chapter deals with Test-driven Development, and if we were Test-driven Development purists, we can argue about the use of mock objects and be more inclined to use real ones. Martin Fowler calls these two styles the classical and mockist Test-driven Development dichotomy in his great article Mocks aren't stubs, which can be read online at http://www.martinfowler.com/articles/mocksArentStubs.html.

Independent of this discussion, we are introducing mock objects as one of the available building blocks because, sometimes, using mock objects in our tests is recommended, desirable, useful, or even unavoidable.

The Android SDK provides the following classes in the subpackage android.test.mock to help us:

  • MockApplication: This is a mock implementation...

The demonstration application


A very simple application has been created to demonstrate the use of some of the tests in this chapter. The source for the application can be downloaded from the Packt website at http://packtpub.com

The following screenshot shows this application running:

When reading the explanation of the tests in this chapter, at any point, you can refer to the demo application that is provided in order to see the test in action. The previous simple application has a clickable link, text input, click on a button and a defined layout UI, we can test these one by one.

Assertions in depth


Assertions are methods that check for a condition that can be evaluated. If the condition is not met, the assertion method will throw an exception, thereby aborting the execution of the test.

The JUnit API includes the class Assert. This is the base class of all the TestCase classes that hold several assertion methods useful for writing tests. These inherited methods test for a variety of conditions and are overloaded to support different parameter types. They can be grouped together in the following different sets, depending on the condition checked, for example:

  • assertEquals

  • assertTrue

  • assertFalse

  • assertNull

  • assertNotNull

  • assertSame

  • assertNotSame

  • fail

The condition tested is pretty obvious and is easily identifiable by the method name. Perhaps the ones that deserve some attention are assertEquals() and assertSame(). The former, when used on objects, asserts that both objects passed as parameters are equally calling the objects' equals() method. The latter asserts that both objects...

View assertions


The assertions introduced earlier handle a variety of types as parameters, but they are only intended to test simple conditions or simple objects.

For example, we have asertEquals(short expected, short actual) to test short values, assertEquals(int expected, int actual) to test integer values, assertEquals(Object expected, Object expected) to test any Object instance, and so on.

Usually, while testing user interfaces in Android, you will face the problem of more sophisticated methods, which are mainly related with Views. In this respect, Android provides a class with plenty of assertions in android.test.ViewAsserts (see http://developer.android.com/reference/android/test/ViewAsserts.html for more details), which test relationships between Views and their absolute and relative positions on the screen.

These methods are also overloaded to provide different conditions. Among the assertions, we can find the following:

  • assertBaselineAligned: This asserts that two Views are aligned...

Even more assertions


If the assertions that are reviewed previously do not seem to be enough for your tests' needs, there is still another class included in the Android framework that covers other cases. This class is MoreAsserts (http://developer.android.com/reference/android/test/MoreAsserts.html).

These methods are also overloaded to support different parameter types. Among the assertions, we can find the following:

  • assertAssignableFrom: This asserts that an object is assignable to a class.

  • assertContainsRegex: This asserts that an expected Regex matches any substring of the specified String. It fails with the specified message if it does not.

  • assertContainsInAnyOrder: This asserts that the specified Iterable contains precisely the elements expected, but in any order.

  • assertContainsInOrder: This asserts that the specified Iterable contains precisely the elements expected, but in the same order.

  • assertEmpty: This asserts that an Iterable is empty.

  • assertEquals: This is for some Collections...

The TouchUtils class


Sometimes, when testing UIs, it is helpful to simulate different kinds of touch events. These touch events can be generated in many different ways, but probably android.test.TouchUtils is the simplest to use. This class provides reusable methods to generate touch events in test cases that are derived from InstrumentationTestCase.

The featured methods allow a simulated interaction with the UI under test. The TouchUtils class provides the infrastructure to inject the events using the correct UI or main thread, so no special handling is needed, and you don't need to annotate the test using @UIThreadTest.

TouchUtils supports the following:

  • Clicking on a View and releasing it

  • Tapping on a View (touching it and quickly releasing)

  • Long-clicking on a View

  • Dragging the screen

  • Dragging Views

The following test represents a typical usage of TouchUtils:

    public void testListScrolling() {
        listView.scrollTo(0, 0);

        TouchUtils.dragQuarterScreenUp(this, activity); 
      ...

Mock objects


We have seen the mock objects provided by the Android testing framework in Chapter 1, Getting Started with Testing, and evaluated the concerns about not using real objects to isolate our tests from the surrounding environment.

The next chapter deals with Test-driven Development, and if we were Test-driven Development purists, we can argue about the use of mock objects and be more inclined to use real ones. Martin Fowler calls these two styles the classical and mockist Test-driven Development dichotomy in his great article Mocks aren't stubs, which can be read online at http://www.martinfowler.com/articles/mocksArentStubs.html.

Independent of this discussion, we are introducing mock objects as one of the available building blocks because, sometimes, using mock objects in our tests is recommended, desirable, useful, or even unavoidable.

The Android SDK provides the following classes in the subpackage android.test.mock to help us:

  • MockApplication: This is a mock implementation of...

The TestCase base class


This is the base class of all other test cases in the JUnit framework. It implements the basic methods that we were analyzing in the previous examples (setUp()). The TestCase class also implements the junit.framework.Test interface, meaning it can be run as a JUnit test.

Your Android test cases should always extend TestCase or one of its descendants.

The default constructor

All test cases require a default constructor because, sometimes, depending on the test runner used, this is the only constructor that is invoked, and is also used for serialization.

According to the documentation, this method is not intended to be used by "mere mortals" without calling setName(String name).

Therefore, to appease the Gods, a common pattern is to use a default test case name in this constructor and invoke the given name constructor afterwards:

public class MyTestCase extends TestCase {
   public MyTestCase() {
      this("MyTestCase Default Name");
   }

   public MyTestCase(String name...

The AndroidTestCase base class


This class can be used as a base class for general-purpose Android test cases.

Use it when you need access to Android resources, databases, or files in the filesystem. Context is stored as a field in this class, which is conveniently named mContext and can be used inside the tests if needed, or the getContext() method can be used too.

Tests based on this class can start more than one Activity using Context.startActivity().

There are various test cases in Android SDK that extend this base class:

  • ApplicationTestCase<T extends Application>

  • ProviderTestCase2<T extends ContentProvider>

  • ServiceTestCase<T extends Service>

When using the AndroidTestCase Java class, you inherit some base assertion methods that can be used; let's look at these in more detail.

The assertActivityRequiresPermission() method

The signature for this method is as follows:

public void assertActivityRequiresPermission(String packageName, String className, String permission)

Description...

Instrumentation


Instrumentation is instantiated by the system before any of the application code is run, thereby allowing monitoring of all the interactions between the system and the application.

As with many other Android application components, instrumentation implementations are described in the AndroidManifest.xml under the tag <instrumentation>. However, with the advent of Gradle, this has now been automated for us, and we can change the properties of the instrumentation in the app's build.gradle file. The AndroidManifest file for your tests will be automatically generated:

defaultConfig {
  testApplicationId 'com.blundell.tut.tests'
testInstrumentationRunner  "android.test.InstrumentationTestRunner"
}

The values mentioned in the preceding code are also the defaults if you do not declare them, meaning that you don't have to have any of these parameters to start writing tests.

The testApplicationId attribute defines the name of the package for your tests. As a default, it is your...

The InstrumentationTestCase class


The InstrumentationTestCase class is the direct or indirect base class for various test cases that have access to Instrumentation. This is the list of the most important direct and indirect subclasses:

  • ActivityTestCase

  • ProviderTestCase2<T extends ContentProvider>

  • SingleLaunchActivityTestCase<T extends Activity>

  • SyncBaseInstrumentation

  • ActivityInstrumentationTestCase2<T extends Activity>

  • ActivityUnitTestCase<T extends Activity>

The InstrumentationTestCase class is in the android.test package, and extends junit.framework.TestCase, which extends junit.framework.Assert.

The launchActivity and launchActivityWithIntent methods

These utility methods are used to launch Activities from a test. If the Intent is not specified using the second option, a default Intent is used:

public final T launchActivity (String pkg, Class<T> activityCls, Bundle extras)

Note

The template class parameter T is used in activityCls and as the return type...

The ActivityTestCase class


This is mainly a class that holds common code for other test cases that access Instrumentation.

You can use this class if you are implementing a specific behavior for test cases and the existing alternatives don't fit your requirements. This means you are unlikely to use this class unless you want to implement a new base class for other tests to use. For example, consider a scenario where Google brings out a new component and you want to write tests around it (like SuperNewContentProvider).

If this is not the case, you might find the following options more suitable for your requirements:

  • ActivityInstrumentationTestCase2<T extends Activity>

  • ActivityUnitTestCase<T extends Activity>

The abstract class android.test.ActivityTestCase extends android.test.InstrumentationTestCase and serves as a base class for other different test cases, such as android.test.ActivityInstrumentationTestCase, android.test.ActivityInstrumentationTestCase2, and android.test.ActivityUnitTestCase...

Left arrow icon Right arrow icon

Description

If you are an Android developer looking to test your applications or optimize your application development process, then this book is for you. No previous experience in application testing is required.

Who is this book for?

If you are an Android developer looking to test your applications or optimize your application development process, then this book is for you. No previous experience in application testing is required.

What you will learn

  • Apply testing techniques and utilize tools to improve Android application development
  • Get to grips with the nuances of testing on Android, including how to architect an application to facilitate better testing
  • Explore the Android instrumentation testing framework to optimize your activities, services, content providers, and usage of other Android components
  • Understand different development methodologies including Testdriven Development and Behaviordriven Development
  • Apply the continuous integration technique for ultimate application quality control
  • Improve application performance by analyzing the results returned from performance tests
  • Expose your application to a wide range of conditions and configurations to simulate reallife network conditions and detect problems in the application
  • Explore further tools to improve application quality such as micro benchmarks and code coverage
Estimated delivery fee Deliver to Russia

Economy delivery 10 - 13 business days

$6.95

Premium delivery 6 - 9 business days

$21.95
(Includes tracking information)

Product Details

Country selected
Publication date, Length, Edition, Language, ISBN-13
Publication date : Mar 26, 2015
Length: 274 pages
Edition : 1st
Language : English
ISBN-13 : 9781784395339
Vendor :
Google
Category :
Languages :
Tools :

What do you get with Print?

Product feature icon Instant access to your digital eBook copy whilst your Print order is Shipped
Product feature icon Paperback book shipped to your preferred address
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
OR
Modal Close icon
Payment Processing...
tick Completed

Shipping Address

Billing Address

Shipping Methods
Estimated delivery fee Deliver to Russia

Economy delivery 10 - 13 business days

$6.95

Premium delivery 6 - 9 business days

$21.95
(Includes tracking information)

Product Details

Publication date : Mar 26, 2015
Length: 274 pages
Edition : 1st
Language : English
ISBN-13 : 9781784395339
Vendor :
Google
Category :
Languages :
Tools :

Packt Subscriptions

See our plans and pricing
Modal Close icon
$19.99 billed monthly
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Simple pricing, no contract
$199.99 billed annually
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts
$279.99 billed in 18 months
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts

Frequently bought together


Stars icon
Total $29.97 $117.97 $88.00 saved
Gradle for Android
$38.99
Learning Android Application Testing
$54.99
Asynchronous Android Programming
$54.99
Total $29.97$117.97 $88.00 saved Stars icon
Banner background image

Table of Contents

10 Chapters
1. Getting Started with Testing Chevron down icon Chevron up icon
2. Understanding Testing with the Android SDK Chevron down icon Chevron up icon
3. Baking with Testing Recipes Chevron down icon Chevron up icon
4. Managing Your Android Testing Environment Chevron down icon Chevron up icon
5. Discovering Continuous Integration Chevron down icon Chevron up icon
6. Practicing Test-driven Development Chevron down icon Chevron up icon
7. Behavior-driven Development Chevron down icon Chevron up icon
8. Testing and Profiling Performance Chevron down icon Chevron up icon
9. Alternative Testing Tactics Chevron down icon Chevron up icon
Index Chevron down icon Chevron up icon

Customer reviews

Rating distribution
Full star icon Full star icon Full star icon Half star icon Empty star icon 3.8
(4 Ratings)
5 star 25%
4 star 50%
3 star 0%
2 star 25%
1 star 0%
Rob Davies Apr 04, 2016
Full star icon Full star icon Full star icon Full star icon Full star icon 5
Saved me a lot of time researching.
Amazon Verified review Amazon
alf_biker Jun 06, 2017
Full star icon Full star icon Full star icon Full star icon Empty star icon 4
Provides a good starting point for doing android testing with Android Studio.
Amazon Verified review Amazon
Jinu Apr 13, 2017
Full star icon Full star icon Full star icon Full star icon Empty star icon 4
Good book to start but it does not have substantial code in it for absolute beginners to understand.And the testing Framework used in this book is currently deprecated.
Amazon Verified review Amazon
Jimi Damon Jul 15, 2016
Full star icon Full star icon Empty star icon Empty star icon Empty star icon 2
I bought this book hoping that I could apply some android testing techniques to some of the apps that I build for work. What I found is a book that , perhaps to no fault of the authors, hasn't caught up with Google's perpetually ( and nauseatingly ) changing Gradle infrastructure combined with AndroidStudio. So, what happens is that when you try to download their samples off of Packet Publishing is that you get source code that barely works. For instance, a number of their example JUnit tests completely fail because permissions weren't set correctly in an AndroidManifest file . This isn't really entirely the authors' fault because Google has been screwing with this for the last 5 years or so. But there are other issues as well. The book doesn't give you good instruction on how to set up any of the advanced testing they are doing by way of Android Studio. As anyone who is doing Android programming, Android Studio is considered both the solution and cause of every problem related to Android . Hence, if you write a book explaining how to do something with Android and you don't provide some examples that show you how to say enable permissions for a Junit test for modifying bookmars from within Android Studio, you are doing your readers a disservice.I found that the book just mentions a bunch of types of tests you can use , something you could learn from any other book on testing software, but offers no real good or working examples of how to use those techniques to test the Android UI or an App's services...etc.
Amazon Verified review Amazon
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

What is the delivery time and cost of print book? Chevron down icon Chevron up icon

Shipping Details

USA:

'

Economy: Delivery to most addresses in the US within 10-15 business days

Premium: Trackable Delivery to most addresses in the US within 3-8 business days

UK:

Economy: Delivery to most addresses in the U.K. within 7-9 business days.
Shipments are not trackable

Premium: Trackable delivery to most addresses in the U.K. within 3-4 business days!
Add one extra business day for deliveries to Northern Ireland and Scottish Highlands and islands

EU:

Premium: Trackable delivery to most EU destinations within 4-9 business days.

Australia:

Economy: Can deliver to P. O. Boxes and private residences.
Trackable service with delivery to addresses in Australia only.
Delivery time ranges from 7-9 business days for VIC and 8-10 business days for Interstate metro
Delivery time is up to 15 business days for remote areas of WA, NT & QLD.

Premium: Delivery to addresses in Australia only
Trackable delivery to most P. O. Boxes and private residences in Australia within 4-5 days based on the distance to a destination following dispatch.

India:

Premium: Delivery to most Indian addresses within 5-6 business days

Rest of the World:

Premium: Countries in the American continent: Trackable delivery to most countries within 4-7 business days

Asia:

Premium: Delivery to most Asian addresses within 5-9 business days

Disclaimer:
All orders received before 5 PM U.K time would start printing from the next business day. So the estimated delivery times start from the next day as well. Orders received after 5 PM U.K time (in our internal systems) on a business day or anytime on the weekend will begin printing the second to next business day. For example, an order placed at 11 AM today will begin printing tomorrow, whereas an order placed at 9 PM tonight will begin printing the day after tomorrow.


Unfortunately, due to several restrictions, we are unable to ship to the following countries:

  1. Afghanistan
  2. American Samoa
  3. Belarus
  4. Brunei Darussalam
  5. Central African Republic
  6. The Democratic Republic of Congo
  7. Eritrea
  8. Guinea-bissau
  9. Iran
  10. Lebanon
  11. Libiya Arab Jamahriya
  12. Somalia
  13. Sudan
  14. Russian Federation
  15. Syrian Arab Republic
  16. Ukraine
  17. Venezuela
What is custom duty/charge? Chevron down icon Chevron up icon

Customs duty are charges levied on goods when they cross international borders. It is a tax that is imposed on imported goods. These duties are charged by special authorities and bodies created by local governments and are meant to protect local industries, economies, and businesses.

Do I have to pay customs charges for the print book order? Chevron down icon Chevron up icon

The orders shipped to the countries that are listed under EU27 will not bear custom charges. They are paid by Packt as part of the order.

List of EU27 countries: www.gov.uk/eu-eea:

A custom duty or localized taxes may be applicable on the shipment and would be charged by the recipient country outside of the EU27 which should be paid by the customer and these duties are not included in the shipping charges been charged on the order.

How do I know my custom duty charges? Chevron down icon Chevron up icon

The amount of duty payable varies greatly depending on the imported goods, the country of origin and several other factors like the total invoice amount or dimensions like weight, and other such criteria applicable in your country.

For example:

  • If you live in Mexico, and the declared value of your ordered items is over $ 50, for you to receive a package, you will have to pay additional import tax of 19% which will be $ 9.50 to the courier service.
  • Whereas if you live in Turkey, and the declared value of your ordered items is over € 22, for you to receive a package, you will have to pay additional import tax of 18% which will be € 3.96 to the courier service.
How can I cancel my order? Chevron down icon Chevron up icon

Cancellation Policy for Published Printed Books:

You can cancel any order within 1 hour of placing the order. Simply contact customercare@packt.com with your order details or payment transaction id. If your order has already started the shipment process, we will do our best to stop it. However, if it is already on the way to you then when you receive it, you can contact us at customercare@packt.com using the returns and refund process.

Please understand that Packt Publishing cannot provide refunds or cancel any order except for the cases described in our Return Policy (i.e. Packt Publishing agrees to replace your printed book because it arrives damaged or material defect in book), Packt Publishing will not accept returns.

What is your returns and refunds policy? Chevron down icon Chevron up icon

Return Policy:

We want you to be happy with your purchase from Packtpub.com. We will not hassle you with returning print books to us. If the print book you receive from us is incorrect, damaged, doesn't work or is unacceptably late, please contact Customer Relations Team on customercare@packt.com with the order number and issue details as explained below:

  1. If you ordered (eBook, Video or Print Book) incorrectly or accidentally, please contact Customer Relations Team on customercare@packt.com within one hour of placing the order and we will replace/refund you the item cost.
  2. Sadly, if your eBook or Video file is faulty or a fault occurs during the eBook or Video being made available to you, i.e. during download then you should contact Customer Relations Team within 14 days of purchase on customercare@packt.com who will be able to resolve this issue for you.
  3. You will have a choice of replacement or refund of the problem items.(damaged, defective or incorrect)
  4. Once Customer Care Team confirms that you will be refunded, you should receive the refund within 10 to 12 working days.
  5. If you are only requesting a refund of one book from a multiple order, then we will refund you the appropriate single item.
  6. Where the items were shipped under a free shipping offer, there will be no shipping costs to refund.

On the off chance your printed book arrives damaged, with book material defect, contact our Customer Relation Team on customercare@packt.com within 14 days of receipt of the book with appropriate evidence of damage and we will work with you to secure a replacement copy, if necessary. Please note that each printed book you order from us is individually made by Packt's professional book-printing partner which is on a print-on-demand basis.

What tax is charged? Chevron down icon Chevron up icon

Currently, no tax is charged on the purchase of any print book (subject to change based on the laws and regulations). A localized VAT fee is charged only to our European and UK customers on eBooks, Video and subscriptions that they buy. GST is charged to Indian customers for eBooks and video purchases.

What payment methods can I use? Chevron down icon Chevron up icon

You can pay with the following card types:

  1. Visa Debit
  2. Visa Credit
  3. MasterCard
  4. PayPal
What is the delivery time and cost of print books? Chevron down icon Chevron up icon

Shipping Details

USA:

'

Economy: Delivery to most addresses in the US within 10-15 business days

Premium: Trackable Delivery to most addresses in the US within 3-8 business days

UK:

Economy: Delivery to most addresses in the U.K. within 7-9 business days.
Shipments are not trackable

Premium: Trackable delivery to most addresses in the U.K. within 3-4 business days!
Add one extra business day for deliveries to Northern Ireland and Scottish Highlands and islands

EU:

Premium: Trackable delivery to most EU destinations within 4-9 business days.

Australia:

Economy: Can deliver to P. O. Boxes and private residences.
Trackable service with delivery to addresses in Australia only.
Delivery time ranges from 7-9 business days for VIC and 8-10 business days for Interstate metro
Delivery time is up to 15 business days for remote areas of WA, NT & QLD.

Premium: Delivery to addresses in Australia only
Trackable delivery to most P. O. Boxes and private residences in Australia within 4-5 days based on the distance to a destination following dispatch.

India:

Premium: Delivery to most Indian addresses within 5-6 business days

Rest of the World:

Premium: Countries in the American continent: Trackable delivery to most countries within 4-7 business days

Asia:

Premium: Delivery to most Asian addresses within 5-9 business days

Disclaimer:
All orders received before 5 PM U.K time would start printing from the next business day. So the estimated delivery times start from the next day as well. Orders received after 5 PM U.K time (in our internal systems) on a business day or anytime on the weekend will begin printing the second to next business day. For example, an order placed at 11 AM today will begin printing tomorrow, whereas an order placed at 9 PM tonight will begin printing the day after tomorrow.


Unfortunately, due to several restrictions, we are unable to ship to the following countries:

  1. Afghanistan
  2. American Samoa
  3. Belarus
  4. Brunei Darussalam
  5. Central African Republic
  6. The Democratic Republic of Congo
  7. Eritrea
  8. Guinea-bissau
  9. Iran
  10. Lebanon
  11. Libiya Arab Jamahriya
  12. Somalia
  13. Sudan
  14. Russian Federation
  15. Syrian Arab Republic
  16. Ukraine
  17. Venezuela