Splitting tests for maintainability and readabilityTestdroid Recorder offers good functionality to keep tests easily maintainable by dividing them into many test methods (and dividing a test-method into smaller parts but that is discussed futher in other section). With these practices you can easily extend your test suite later, when there are changes in the application, new features and/or changes in the views.
Plan your test cases and split them into scenarios. Every scenario should be recorded into a separate test method. You can read more on how to add methods, change current recording method and more in Testdroid Recorder Tutorials.
Be careful when you changing recording current recording method. Pay attention where you are in a new method (in which activity) and keep in mind that tests don't necessarily run in the same order as you might expected (in the same order you created new methods or in alphabetical order), because it is not ensured by JUnit.
When you playback tests, every next test method starts clean and your application is therefore restarted. This means that in every test method your application will be in its first activity. So if you create new test method, switch recording to the method and just continue recording for instance from 4th activity your test will be failed on playback.
That's why the best approach to deal with recording is as follows:
- create new test method
- pause recording
- go to first screen(in pause state nothing is recording)
- copy waitForActivity(first activity) command from first method and paste it at the beginning on the second method and then back to recording and go to place you are interested.
step 1: record first method
step 2: pause recording, go in phone to first activity and copy first activity(or activities if there is any splash screen) from first method
step 3: paste the activities and unpause recording and go ahead further
WORK-AROUND FOR LOGIN PROBLEMOften login view in application cause difficulties by playback test. Let's assume you record first time from your application and first screen is login - you recorded login steps and next other scenarios. Now you playback test locally and test crashed because your test tries to put login into EditText for instance but login screen is not shown again because you are remembered in application data. You might think this isn't a problem because you can remove the part with the login logic but unfortunately if you're going to run this test in Testdroid Cloud this is no good as in our Cloud service the application is reinstalled on each test. So every new loaded test comes with clear data that's why we need to keep login part.
Another problem with recorded login steps is again problem with method order by playback test which, as I mentioned in a previous section, may be random (usually it is alphabetical order but it's not guaranteed by jUnit).
The following are a few useful tips to deal with this problem:
- You can keep flag which designate if you did login already and check this flag in every test method on the beginning(the best option is to put it inside setUp method which is run before every test method). If it is not set then do login logic and set the flag, in other case just skip login logic.
- You can try to find the login at the beginning of every test method(or as I mentioned above - in the setUp method) if the login is in the current view or a Button exists for login or other widget for login view. Below is example of this:
If you have any other idea feel free to share your solution, and we can post it here.
SUB-METHODS FOR READABILITYThere are some good reasons you could use submethodes in your tests:
- Readability For instance, you can move recorded login logic to a sub-method.
- Repeatability For example you may need to go through three activity to start recording every scenario and you decided to split every scenario into separate test methods. When you record it first time just next copy and paste it in to every other test method.
Sample of put regular actions into sub-methods for better readability.