Good catch! The entire test package contains a *suite* of unit tests against methods in the application under test.
They are unit tests because they test the smallest testable part of the application, which is a single method written by the user. In practice, multiple unit tests are run sequentially in a test suite. Each test is independent, not relying on the results of a previous test. The tests are usually grouped together into a test case class so that each application class has a test case class. All of this is just practice and subject to individual use. JUnit (version 3), on which Android test case classes are based, simplifies this strategy. The special methods setUp() and tearDown() are run before and after each test to ensure that each unit test is independent. Any other method beginning with the string "test" is run as a unit test. The only thing that is different is the environment in which an Android unit test runs. Anything that uses Android has to run within the Android environment. For that reason, simply calling the onCreate() method for one of your Activity classes won't work, because Android has its own lifecycle for objects. That's why the test case class in the example you cite subclasses ActivityInstrumentationTestCase2. It is using both JUnit and InstrumentationTestCase to provide the test case. JUnit allows you to run the test case class like a JUnit test case, while InstrumentationTestCase allows you to use Android instrumentation to control the Activity under test. Even using the virtual machine to run the class under test wouldn't work correctly. The Activity context is a dependency. You can have dependencies in a unit test. It's perfectly OK to run a unit test in a particular context, as long as you have complete control over the context. ActivityInstrumentationTestCase2 gives you this control, as do other mock classes in the Android API. In short, the differences you see between the example and a standard test case are because of the Android environment. I would include unit tests of *everything* in my test suite. It's not so much a matter of it being a GUI, as much as it being a testable unit. A test in which you enter text in an edit box, click a button, and see the result is not necessarily a unit test; I would call it a "functional" test. A test in which you start put text in an edit box, call the method processEditBox(), and look at the result that the method returns *is* a unit test. Putting text in the edit box is setting up a dependency. It seems to me that the key point in a unit test is to isolate the behavior you're testing from all other behaviors in the application, so that you're not unconsciously using external dependencies. I'm interested in hearing the responses of others in your class, and your instructor as well. On Nov 9, 5:47 am, Ians <[email protected]> wrote: > I'm working on a school project and I'm researching testing > possibilities for Android applications. > > On this > page:http://developer.android.com/resources/tutorials/testing/helloandroid... > Google writes about a unit test. > > Is this really a unit test? A Unit test will not integrate all classes > and will not test in his context. So my opinion is it is not a Unit > Test but an Integration Test. > > What do you think? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
