Automated Unit Testing

1. Automated Unit Testing

2. Test Automation • Manual testing is laborious and time consuming. • Computer automation has transformed many sectors of our economy. Why not direct the same technology at the laborious aspects of software testing? • Test automation is the process of using software to automate the manual aspects of software testing. • Automated testing reduces labor required to run tests and speeds up the testing process. • Perhaps the best opportunity for automated testing is during regression testing. • Developers generally feel more confident making a change when there is a large comprehensive suite of regression tests that can be ran against the system under development.

3. Pitfalls of Test Automation • As the number of automated test cases grows, so does the cost of maintaining them. • A failed test doesn’t always mean a problem with the software. It can mean an assumption made when the test was written is no longer valid. • A large comprehensive suite of automated tests acts as a safety net when making changes but it also increases the amount of software that has to be maintained as the system evolves.

4. Two General Approaches to Test Automation • Automated GUI testing – using specialized (and expen$ive) software tools that generates keyboard and mouse input and validates the observable behavior of the program is correct. Mercury Interactive (now part of HP) offers automated UI testing software. • Automated unit testing – writing routines to test procedures and the public interfaces of classes.

5. Testing Metrics • Total number of automated tests. • Number of automated test cases that fail during each build. • % of failures caused by product errors vs. test case errors (or invalid assumptions). • Of the test cases that failed because of an error or now invalid assumption, how many were rewritten vs. thrown away? • Time spent creating new automated test cases. • Time spent maintaining existing tests.

6. Unit Testing Frameworks • Automated unit testing is often done using a framework such as NUnit (.net) or JUnit (Java). • To use one of these xUnit frameworks, you write classes that contain methods which exercise the objects and routines in the code you want to test. • By following certain conventions as you write these automated unit tests, you can easily manage these unit tests using the NUnit/JUnit/XUnit framework.

7. Example Unit Test Frameworks • NUnit for .NET programs • JUnitfor Java • Test::Unit for Ruby • PyUnitfor Python • CppUnitfor C++ • OCUnitfor Objective-C

8. Example Code to test: namespace MyCode { classArithmetic { publicint Add(int i, int j) { return i + j; } } }

9. NUnit Tests [TestFixture] publicclassArithmeticTests { [Test] publicvoidAdd_SimpleTest(){ MyCode.Arithmetic a = newMyCode.Arithmetic(); int answer = a.Add(3,7); Assert.AreEqual(10, answer); } [Test] publicvoidAdd_BigNumbers() { MyCode.Arithmetic a = newMyCode.Arithmetic(); int answer = a.Add(int.MaxValue, 0); Assert.AreEqual(int.MaxValue, answer); } }

10. Output From NUnit

11. Dependency Injection • Objects are more flexible and easier to test when they allow their dependencies to be set by clients. • The following class is not easy to test. It has a dependency on the file “AboutData.txt”. Testing the class involves making sure a file with the proper format exists on the file system. • It can be made easier to test by redesigning it to use Dependency Injection.

12. publicclassAppDescription { privateString name; privateString version; privateString author; publicAppDescription() throwsIOException { BufferedReaderbr = newBufferedReader( newFileReader("AboutData.txt")); name = br.readLine(); version = br.readLine(); author = br.readLine(); br.close(); } publicString getAppDescription() { returnname + " " + version + " was written by " + author; } }

13. public class AppDescription { privateString name; privateString version; privateString author; publicAppDescription() throwsIOException { this(newFileReader("AboutData.txt")); } publicAppDescription(Reader r) throwsIOException { BufferedReaderbr = newBufferedReader(r); name = br.readLine(); version = br.readLine(); author = br.readLine(); br.close(); } publicString getAppDescription() { returnname + " " + version + " was written by " + author; } }

14. Dependency Injection via setter methods • The previous example showed DI via a class’s constructor. You can also inject dependencies via setter methods. public class Dependent { privateAService s1; privateAnotherService s2; public Dependent() { } publicsetAService(AService s) { s1 = s; } publicsetAnotherService(AnotherServices) { s2 = s; } }

15. References

16. Creating and running tests of Android applications in Eclipse with ADT • There are JUnitextensions for Android to test Android components. • Unit tests can be hard to write because application code is often tied to the application’s runtime environment. For example, to create a SQLite DB in android you need the application’s context. This makes it more difficult to write unit tests independent of the application. • JUnit extensions for Android solve the problem. The JUnit extension class android.test.AndroidTestCase provides access to an application’s context.

17. Automated Android Activity Testing • A well-designed program will separate program logic from the user interface. Among other benefits, it makes testing easier. Most program logic can be tested without going through the UI (something that requires physical input), but it does mean the portion code in the view and event handling routines for the view aren’t covered by automated unit tests. • Until now! The Android instrumentation framework provides support for writing automated unit tests that send events to the user interface. • It’s called Activity testing.