On the 5th of November 2015, the 5th Anadea Inc. mini-conference was held. By half past 6 the stereo system was ready, slides uploaded and everybody took their seats. Traditionally, Aleksey Derkach opened the conference.
This time two speeches were devoted to testing: review of Calabash framework by Kirill Machuhin and testing iOS apps from the developer’s point of view by Daria Kovalenko. Also, our guru Dmitriy Kiriyenko shared with the audience some valuable insights on Ruby on Rails code refactoring.
The 1st reporter Dmitriy Kiriyenko: Let me refactor this for you
Dmitriy Kiriyenko gave a talk via Skype from Grodno. It was the first online report in the history of our mini-conferences. Dmitriy didn't only speak but also showed in practice how to make a Ruby on Rails application better.
He explained how to:
- Move logic from controllers to models, so that only dispatching remains in controllers,
- Add non-ActiveRecord models, especially in the cases when the controller operates with more than one model.
The main idea was that the problems should be addressed as they arise and by using the available means, e.g. without spending much time on searching for the right tool or the proper method.
The 2nd reporter Kirill Machuhin: Calabash Android and Calabash iOS - automated testing of mobile applications
After that, the talk about testing began.
Kirill Machuhin started his report with the question: What tool would you use for automated testing in the project? He specified all the requirements for such a tool and then introduced the framework that fully match them - Calabash.
Set of tools:
- Calabash Android,
- Calabash iOS,
- Gherkin Syntax (Cucumber style),
- Calabash Android last updated - 26 days ago,
- Calabash iOS last updated - a month ago,
- Launching on the real devices.
Kirill described how to get started with it: install, run and then reviewed the differences between Android and iOS versions. He showed that, till a certain phase, the same code should be written and suggested a way of avoiding the duplication. The solution is quite trivial and simple: install gems on the server side, i.e. extract Calabash out of our mobile projects; divide
page_object into modules and glue together
The pros of such implementation:
- we don’t have a duplicated code (
- we have an easy access to the objects via ActiveRecord,
- emulation of the second client is working on the server side.
- different launch commands (cucumber, calabash-android run),
- it is impossible to work in the debug mode provided by Calabash.
Also, he explained how to get rid of the implementation's cons.
The 3rd reporter Darya Kovalenko: Testing iOS apps or how I fell in love with writing tests
When all the questions from the audience were answered, Kirill passed the microphone to Darya Kovalenko. Darya continued the topic about testing with her story about testing in iOS from the developer’s point of view. She talked about why the developers write the tests, about integration tests and why KIF best suits them.
- Syntax in Objective-C,
- It is added via pod into current or new test target,
- Opportunity of using OCMock stubs and expects.
Dasha told about the benefits of using integration tests:
- One test executes several actions at once. Therefore, you can quickly cover a large amount of code with tests.
- It saves your time when it is necessary to run the app to check how the main functions operate.
- It is easy to catch the little things, especially at switching between screens that are difficult to check with unit-tests.
And about cons:
- If the test-scenario fails on the half way, next ones will not pass because the application is not restarted.
- It uses a private API, so some functions do not work after updating iOS.
- Tests pass quite slow.
- Tests may fail if showing of keyboard is turned off, if the system screens pop up, etc.)
- It is connected to the accessibility labels.
It also was discussed, why it is better to write the tests first and than the code:
- It allows to think through the structure of the class in more detail.
- You can describe possible variations of the method's behavior in the tests and then write the code that meets all the requirements.
- You have to split the methods into the smaller ones for testing.
- Because it is difficult to make yourself to write the tests afterwards :)
When the last speaker received applause, pizza and cola replaced the projector and slides. As usually, in a friendly atmosphere the guys from our company continued to discuss the topics presented in reports. The record of the conference can be found here.