Episode 25: How It’s Made — Freeletics

[arturdryomov]

No description provided.

[qazt482]

Overall, interesting episode. A few things I would like to mention:

Complaints about Android Studio and Gradle - please note Android Studio is a fork of the Community version of IntelliJ maintained by Goole. Issues with Gradle are also due to the android-gradle plugin, also maintained by Google.

I have used IntelliJ and gradle for serverside projects and the experience was solid - the (slow) android dev experience is all down to Google. Going to Eclipse is NOT a solution!

Testing - I think once you start introducing devices/emulators, you reach another level when it comes to maintenance - you will spend more time dealing with flakiness and long builds.

I was quite shocked to hear you would consider turning the testing pyramid upside down. Its been around for many years and is the culmination of a lot of experience - Android does not change this.

I worked on a project a few years ago where it was like this (server side web). The technical lead described it as a "mushroom". The tests were written by Java-certified testers. The code was terrible, badly (if at all) maintained. The tests would take so long to run that they could only be run overnight. And due to flakiness, they never once completed a full run with complete success. In the end, they would say "90% passed, thats good enough to release"!

There are other reasons the pyramid is like it is - I don't want to go over them here.

There was also talk about ditching the current code review process and going straight to master and releasing. Hmmm, I'm pretty sure thats what I did server side!

[vanniktech]

Is the Git release missing? I thought this episode wasn't out.

[arturdryomov]

@qazt482, thanks for the feedback! It is rare to see it so it is always valuable 😉

[sockeqwe]

@vanniktech Thanks, we forgot to upload it. Actually we were discussing dropping release section (amongst some other restructuring things). We were wondering: do you find the release section useful and why? Don't you use a podcast player anyway?

@qazt482 Thanks a lot for your feedback!

Complaints about Android Studio and Gradle - please note Android Studio is a fork of the Community version of IntelliJ maintained by Goole. Issues with Gradle are also due to the android-gradle plugin, also maintained by Google.

Very true, I think we have mentioned that on previous episodes already.

Testing - I think once you start introducing devices/emulators, you reach another level when it comes to maintenance - you will spend more time dealing with flakiness and long builds.

Mostly true but from my experience flakyness can be avoided / reduced quite a bit with a proper architecture. Also, we can run a functional test specification on both, Android Emulator with real View layer and as inside the JVM with a mocked View Layer. We run the test with real android view inside Emulator on CI exclusively whereas JVM tests of the same spec are part of your TDD cycle. Example:

• Have one specification: https://github.com/freeletics/RxRedux/blob/master/sample/src/testSpec/java/com/freeletics/rxredux/PopularRepositoriesSpec.kt#L135
• Make this specification run on Android emulator with real View layer: https://github.com/freeletics/RxRedux/blob/master/sample/src/androidTest/java/com/freeletics/rxredux/PopularRepositoriesActivityTest.kt#L54
• Make the same specification run on jvm with mocked View layer: https://github.com/freeletics/RxRedux/blob/master/sample/src/test/java/com/freeletics/rxredux/PopularRepositoriesJvmTest.kt#L78

I was quite shocked to hear you would consider turning the testing pyramid upside down. Its been around for many years and is the culmination of a lot of experience - Android does not change this.

I do understand your point of view. My point is the following: We do write unit tests like testing a single method of a class but in the past it was mostly to cumbersome to write an integration test / functional test for a method of a single class? Why? Because of object oriented programming, mutable fields and side effects. That's the main reason why a developer tends to write unit tests: Because you have to run your test every single method call in isolation or in an isolated environment controlled by the caller of this method like you do it in unit tests. Plus you have to use mocks. Another argument is they are faster to execute compared to functional tests. That is true if you compare with functional test but mostly because of real View Layer. If you don't use real View Layer you are back to almost the same speed as simple unit tests.

Another point I made during the episode is that if you write mostly pure functions (i.e. with RxJava) you can easily test those functions during functional tests instead of unit tests because you are basically the same function again but also how it is integrated with other components plus since it is a pure function you don't have to isolate it just to test it (which is true in the world of object oriented programming with unit tests).

Thanks for your feedback and to start this discussion 🙇

[vanniktech]

We were wondering: do you find the release section useful and why? Don't you use a podcast player anyway?

No. I just look at the release notes, download the MP3 and drop it into my Google Drive and then from my phone/Google Home I listen to it whenever I feel like listening to it.

[erickok]

I also just Watch this repo and download the mp3 when they are in Releases. 😃 The episode was interesting since some controversial opinions were unleashed...

As for future topics I'd also be interested in/if people use other languages, perhpas pure FP, if they learned from non-Android framework, etc.