On Dec 15, 12:39 pm, Etienne <[email protected]> wrote: > > How do you go about creating an object with all the dependencies set to > known values by injection? >
Depends on what type of object you're talking about, and what test case class you're using. ActivityInstrumentationTestCase2 runs in a real Android environment, so it uses a normal Context object and interacts with the Activity's UI in a normal way. To ensure you're using the "environment" you want, you can modify the Context and set up a fixture for the test in setUp(). You can't *inject* dependencies, but you can set up your dependencies to a known state. For example, you can use setUp() to preload a content provider that your Activity uses. A set of POJOs, properly designed, would require minimal or no external dependencies. My favorite example of such an object is an ordered collection object. Properly designed, you should be able to inject a sort algorithm and a comparison algorithm. > So if i am in the LoginActivity and i want to enter fields into EditText > views such as a username and password > and then click a button to login which starts another activity that makes a > REST call with the appropriate login > signature and the second activity parses the XML response which is returned > back to the LoginActivity, is there > no way of testing that whole process with ActivityInstrumentationTestCase2 > or ActivityUnitTestCase? > In general, you can't test more than one object at a time in a unit test. You don't *want* to do this. In a unit test, you're testing the methods in *one* object; everything else is assumed to be working. Anything that you need to supply to the method under test should either be "atomic" (an integer, for example) or a mock object (something whose state you can easily establish). In the case you propose, the second Activity either has to be a mock, or you have to assume it is. If you test LoginActivity, you must assume that the second Activity is working. > Also you say that: > > > > >Both ActivityUnitTestCase and ActivityInstrumentationTestCase2 are (IMHO) > "pseudo-unit" test > >cases. > > Then what types of tests are appropriate in each class? I would use ActivityInstrumentationTestCase2. I suspect, although I am not sure, that ActivityUnitTestCase was provided for the sake of "purity". Since it's isolated from the rest of the Android environment, you can say that it does a true unit test. I'm not sure that there's a need for this. Test-driven development and unit testing require a different and sometimes orthogonal mindset to traditional OOP development techniques. Sometimes you have to be strict with yourself. If you find yourself wanting to control the interaction of two objects in order to test them, then you have to mock one of them. -- 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
