Backwards navigation with Navigation Component isn't a mystery, is it? We don't have to do anything, we have it for free.

But, what if you want to navigate straight to a specific destination? And be able to navigate back to the start destination? Like if you had navigated manually to that specific destination.

I expected that the backwards navigation continues working but it doesn't. And this is the reason that this article exists.

Note: deep linking provides this behaviour. It simulates manual navigation and creates a synthetic back stack.

Understanding the back stack

The first thing is to understand what the back stack is and how it works with the Navigation component. The back stack is a LIFO stack that stores the activity and its fragments. The last fragment pushed onto the back stack will be the first fragment popped off the stack when we hit the back button.

For example, if we have the following navigation:

Fragment A -> Fragment B -> Fragment C

Its back stack will look like this:

If we hit the back button, the fragment on the top is popped off the stack and now Fragment B is in the foreground:

Hit the back button again and Fragment B is popped off the stack:

Finally, if we hit the back button one more time, Fragment A and the activity are popped off the stack and we exit the app:

This backwards navigation behaviour comes for free, we don't have to do anything.

Problem

The described behaviour works as long as we navigate manually to a destination. Yet, what if we want to navigate to a specific destination skipping destinations in between? And be able to navigate back to the start destination?

You can think of a sign-up flow for example. You may want to let the user leave the flow at any point. And allow him to rejoin the flow at the last point he left (and don't lose a user because of a long sign-up process).

In this case, the backwards navigation isn't what we expect. If we navigate straight to Fragment C and hit the back button, we won't see Fragment B. We'll see Fragment A. What is happening is that Fragment B wasn't pushed onto the back stack because we never navigated to it.

Solution

To amend this problem, the solution I've found is that we have to build the back navigation ourselves.

Show me the code

You can find the code here (artificial-back-stack branch).

The aim is to have a navigation graph where all the destinations are connected forwards and backwards:

For this example, I'll have HomeFragment as the start destination; and FirstFragment, SecondFragment and, ThirdFragment as destinations.

The graph will look like this:

Once we have the forwards navigation, we have to build the backwards navigation. Thus, when we navigate straight to a destination, we're still able to navigate back to the start destination. For that, we have to add the actions for the backwards navigation:

We also have to provide custom back navigation to our fragments and specify the action. For example, this is how we'd provide custom back navigation to FirstFragment:

Everything seems to work fine. We can navigate through the navigation graph forwards and backwards. However, when we navigate back to the HomeFragment, we'll notice a bug. We enter a loop between the HomeFragment and the FirstFragment and can't exit the app:

What is happening?

Let's analyse the back stack to understand what is happening. The back stack when we launch the app:

We navigate to the FirstFragment and then to the SecondFragment:

When we hit the back button, because of the action_secondFragment_to_firstFragment action, a new destination (FirstFragment) is added:

Hit the back button again and, because of the action_firstFragment_to_homeFragment action, a new HomeFragment is added:

Back button again and the HomeFragment is popped off the stack (FirstFragment is visible again). Hit back again and a new HomeFragment is added, and so on:

How to fix the loop bug

We have to specify the app:popUpTo attribute in the action_firstFragment_to_homeFragment action. By including app:popUpTo="@id/homeFragment", we're telling the navigation graph that all the destinations are popped off the stack until reaching the specified destination (HomeFragment). With this attribute, we've fixed the loop bug.

However, there is a new bug. We need to hit the back button twice when we're in the HomeFragment to exit the app:

Let's analyse the back stack again to understand why this new bug is happening. The back stack when we navigate to the FirstFragment and then to the SecondFragment:

Let's start hitting the back button, a new FirstFragment is pushed onto the back stack:

Because of app:popUpTo="@id/homeFragment", when we hit the back button again, all the fragments are popped off the stack until reaching the destination HomeFragment. And a new HomeFragment is pushed onto the back stack:

Now we have two HomeFragment instances and this is the reason why we need to hit the back button twice to exit the app.

How to fix this new bug

The app:popUpToInclusive attribute fixes the bug:

This attribute pops the target off the stack as well:

Now we only have one HomeFragment in the back stack and hitting the back button once will exit the app:

You can learn more about app:popUpTo and app:popUpToInclusive here (skip to the Pop additional destinations off the back stack section).

That's all

I don't know if there is a better way of achieving this. I couldn't find anything that solves this problem. After investigation, this is the solution I came up with.

1. Start a session

   git bisect start
   

2. Set the bad commit

   Either the current commit you're checked out has the bug

   git bisect bad
   

   or a specific commit has the bug, for example, dcf12e8

   git bisect bad dcf12e8
   

3. Set the good commit (e.g. eff13d3 doesn't have the bug )

   git bisect good eff13d3
   

4. Run and test the application yourself (you have to tell Git if the bug is there or not)

   Either the bug is present, then run

   git bisect bad
   

   or the bug is not present, then run

   git bisect good
   

5. Repeat step 4 until the first bad commit is found

Note: you can use tags instead of commit hashes as well.

When is it useful?

I usually find it quite useful when the two following conditions are met:

• The bug was not present in the latest release but it's present in the current release candidate
• I have no idea what is causing the bug (therefore I don't know where to look)

Imagine the following scenario. A new release (let's say 2.80) is about to be released and QA is doing regression. You're enjoying a deserved coffee after a job well done when, unexpectedly, you're tagged on Slack...you know that it's not a good signal...

So, you've just been informed that a blocker was found during regression and it has to be fixed. At this point, several thoughts go through your mind:

"Okay, hopefully, it's not my code that is breaking the app so I'm safe" (AKA throw one of your colleagues under the bus)

"Let's look at the ticket, it will surely be something easy to fix. D'oh! It isn't!"

Okay, you have no choice but to fix it. You read the ticket and the bug is odd. You don't have a clue why it's failing and what is causing it.

The only thing you know for sure is that 2.80 has the bug but 2.79 doesn't. Then, git bisect is your friend in this scenario.

How it works under the hood

Git Bisect relies on the binary search algorithm to find the first bad commit (the commit that introduced the bug). So, let's start by starting the session:

git bisect start

Then, we have to let Git know which commit has the bug for sure and which one doesn't. We know that 2.80 has the bug and that 2.79 doesn't, so:

git bisect bad 2.80 (or git bisect bad if the current commit has the bug)

git bisect good 2.79

At this point, our setup is something like this:

Then Git automatically checks out a commit in the middle and we have to run the application to check if the bug is present or not:

Let's say that the bug is present in C3 (dcf12e8), then we know that the second half has the bug for sure, therefore, the bug was introduced somewhere in the first half. We have to let Git know that C3 has the bug:

git bisect bad dcf12e8

Now Git automatically checks out a new commit:

Let's say now that the bug is not present in C1 (eff13d3), then we have to let Git know about this:

git bisect good eff13d3

So the first half is bug-free, therefore, it is discarded. Only the C2 commit is left and Git checks it out, we run the app and let's say that the bug is present. Bingo! The first bad commit has just been found (because C1 is bug-free):

Finally, Git will provide you with the hash (author, date, etc.) of the first bad commit.

Final thoughts

git bisect is not the Holy Grail, sometimes even if you find the commit that introduced the bug, it's simply not enough to figure out what the problem is.

But, even so, it's a skill that can help you to discard possible scenarios and fence the problem.

Documentation

https://git-scm.com/docs/git-bisect
https://www.git-tower.com/learn/git/faq/git-bisect/

Images used

https://unsplash.com/photos/IClZBVw5W5A

First things first. Why add a new library for testing into the project if I already use Mockito and/or Powermock and those are just fine? We tested before MockK, didn't we? What's the benefit of adding it now?

Kotlin, the answer is Kotlin. Google announced Kotlin as a preferred language for Android at Google I/O 2017. And since then, the language has become more and more popular. The latest Stack Overflow's Developer Survey (2020) shows this trend:

So, given its first-class status in the Android ecosystem and its good reception by developers, we can say that Kotlin is here to stay. Even so, do we need MockK? If I was asked this question, I'd answer a "no". We don't need it, same as we don't need Kotlin to develop Android applications. However, I like MockK for reasons like:

Interoperability

We can test both, Java and Kotlin files, so we are not limited to only Kotlin code which means that we can test old projects written in Java with MockK.

Final classes

Is the following error familiar to you when testing Kotlin code with Mockito?

Mockito cannot mock/spy because :
- final class

Classes in Kotlin are final by default to prevent inheritance (you have to define a class as open if you want to make it inheritable).

With MockK you don't need to do any workaround to fix the above error, it just works.

Extension functions

A nice feature that we have in Kotlin to add more functionalities to classes that we do/don't own (e.g. the String class) are the extension functions and MockK gives us a handy way ( mockkStatic() ) of mocking them.

Tip: you can use mockkStatic() for mocking static methods in Java as well.

Relaxed mocks

How many times have you faced an NPE when running a test? I don't know about you but I've faced it many times myself. One of the reasons for those NPEs is that we forget to set up the behaviour of a mock, in other words, we forget to set up some when(mock.doThis()).thenReturn(...).

We could either set up the missing responses (depending on the mock, it could mean setting up multiple when's) or use relaxed mocks. A relaxed mock returns some simple value for all functions. So we can just focus on setting up the behaviours that we need and forget about the rest.

It's worth it to mention that we can make the mock to return simple values for all functions with relaxed = true:

class UserViewModelTest {

    @MockK(relaxed = true)
    private lateinit var loginService: LoginService

    @Before
    fun setUp() {
        MockitoAnnotations.openMocks(this)
     }
}

Or we can set it up for only functions that return nothing (Unit in Kotlin or void in Java):

class UserViewModelTest {

    @MockK(relaxUnitFun = true)
    private lateinit var loginService: LoginService

    @Before
    fun setUp() {
        MockitoAnnotations.openMocks(this)
     }
}

withArg matcher

When testing, we may want to ensure that an argument contains an expected value. That is not a problem at all, unless this argument is only used internally within a class (either private property or a local argument inside a function), therefore, we can't read its value from outside the class.

I've seen mainly two different approaches of working this around:

• Make the property public so you can read it from outside (every time a developer do this, a new plague is sent to the world)
• Annotate the property with @VisibleForTesting (yeah...it does the job but you can do better and you know it)

The problem with those solutions is that we're modifying the production code for testing purposes. This smells very bad. However, there will be times (too much refactoring, need to deliver, lack of time, etc.) in which we'll have no choice but use them. I'd see them as a plan B.

The best approach to test the above scenario is to "capture" the private/local argument and make assertions on it. Mockito provides us with the ArgumentCaptor feature for this purpose.

Having the following code:

    fun login(username: String, password: String) {
        val user = User(username, password)
        loginService.login(user)
    }

We want to ensure that we're passing the correct User object built from username and password. With ArgumentCaptor:

    @Test
    fun `Argument Captor`() {
        val captor = argumentCaptor<User>()// first step
        val username = "myusername@company.com"
        val password = "12345"
        val userExpected = User(username, password)

        sut.login(username, password)

        verify(loginService).login(captor.capture())// second step
        assertEquals(userExpected, captor.firstValue)// third step
    }

As we can see, we have to follow three steps (define, capture and assertion).

These three steps can be reduced with withArg:

    @Test
    fun `WithArg`() {
        val username = "myusername@company.com"
        val password = "12345"
        val userExpected = User(username, password)

        sut.login(username, password)

        verify {
            persistUsersUseCase.login(
                withArg { assertEquals(userExpected, it) }// capture and assertion
            )
        }
    }

Things that I like with this approach:

• I don't have to define the captor
• I don't have to explicitly capture the value
• I can do everything in just one verification

To conclude

MockK has much more to offer and helps to achieve more writing less. In my first contact with it, I wasn't very happy about having to learn a new tool and I didn't see many advantages of using it (just some specific scenarios) but nowadays I'm happy I gave it a go and it's become an essential in my toolbox.

Bibliography

https://mockk.io/ (official page)

https://blog.kotlin-academy.com/mocking-is-not-rocket-science-mockk-features-e5d55d735a98 (article written by the developer/author of MockK)

https://notwoods.github.io/mockk-guidebook/ (guidebook)

Long answer: Yes, Unit Testing is that important.

If you just searched the web for unit testing, congratulations! You're on the right track. The sooner you start including tests in your code the better.

I wish I knew this when I started my career as an Android developer. I remember being taught about using design patterns such as MVP for decoupling the business logic from the view business and thus, among other things, have testable code. However, we didn't implement tests therefore I never really internalise the benefits of using design patterns nor unit testing. It seemed to me that it only made the project more difficult to understand and follow, code more verbose and I ended up coding in that way because "it was how it was supposed to be done".

It took me years to understand the importance of design patterns and unit testing (that's why it's important to start with unit testing soon) but once you do it, you'll never look back and this is great news.

There are several benefits, technical and non-technical, about unit testing that I've found out over the years.

Technical benefits

Improve our code

We always write clean code, right? RIGHT!? Well, no...not always at least. Unit testing helps us to spot complex logic (e.g. a method that does many things or a bunch of required setup in the test file is a strong indicator that the class under test could be doing many things as well) because complex logic is not easy to test, therefore we may want to refactor it and make it easier to test.

More than once I've had the following thought "Wait...I think I've tested this same behaviour before...". And effectively I find that I already have that same (or similar) logic implemented in the codebase so it's a strong candidate for being extracted as a helper or util and being reused, thus avoid code duplication.

Make our code more reliable

For a Java developer, a crash of the application due to an NPE is as frequent as a lockdown nowadays. The reason is that when you're coding, it's not rare that you take for granted that most of the variables have a value assigned. This is not always the case and testing highlights it before our eyes. You are not going to fix something if you don't even know it's broken. I've named NPE but it applies to more things such as missing to consider conditional branches (if-else).

Spot edge cases

When we code, we think about all the possibilities and/or scenarios that our app may face and we cover them. Or at least we think so. It's very common that when we're testing a piece of code, we find ourselves having the following conversation:

"Okay, so this method receives a list as an argument and it can't be null because I've annotated it as @NonNull therefore I don't have to test the scenario in which the list is null, yeah!!! Hold on, what if the list is empty?"

At this point, new questions arise:

• Should I treat an empty list as an error?
• Should I add a default value/object to the list when it is empty?
• Should I handle the empty list in this method or should the caller to the method handle it and ensure that the list is not empty?

Something as simple as an empty list is a source of questions and unit testing begins to show its power.

Encourage refactoring

Our tests work as a safety net for our production code so, if we have a good test suite, we'll be more willing to refactor if we know unconsciously that we won't break anything without being warned.

Non-technical benefits

Stand out

If you're a less experienced developer in job hunting, knowing about unit testing (even if you're not that great at it yet) can make you stand out among other candidates.

And if you're a more experienced developer and you don't know about testing, you will stand out as well. Not in the way that you want to though.

Detect red flags

If during an interview, you're not asked about unit testing or when you ask about it (you should always ask questions in an interview by the way), the interviewer gives you a vague answer (no mention about code coverage, tools for code quality such as SonarQube, frameworks for testing such as Mockito and Robolectric) for Android, then you know that you have to be in alert to spot more red flags "Do they have code review? What about their CI/CD?" If you spot a lot of red flags, you might want to consider if that is a place where you want to work.

Downsides

Time-consuming

Frequently, you spend more time testing the production code you just wrote than writing the code itself. Especially when you're not used to testing or, even worse, when you have to test legacy code that was never tested, therefore likely not very testable.

Clashes with teammates

If you work in a company in which the culture of testing is little or your teammates barely test their code because they think that testing is not important or a waste of time, most likely there will be frictions. You may need to make the extra effort and educate them.

Conclusion

In my experience, you should add unit testing to your skill set because the benefits outweigh the downsides and there is no turning back. It makes you a better developer because it obliges you to architecture your app, to think about why you're doing things in some way and not in another, to understand why concepts such as single responsibility or decoupling are important and the like.