thesoftwarefactory / lokki-android Goto Github PK

Using Robolectric and possibly Espresso

Should the places circle size be fixed related to the screen instead of the map?
Could be beneficial to be able to change the size of places.

Because of this, one cannot use the back button long-press if needed.

For instance tests that you can enter all navigation drawer links and return from them correctly

If multiple contacts are in the same place on the map only the top contact is shown. Perhaps the icon could indicate that there are multiple contacts stacked underneath

This app is probably not going into the store anytime soon?

Dropdown menus for selections (e.g. Yes/No for "My contacts can see me", Default/Satellite/Hybrid for "Map mode") appear all the way to the left. Should add a margin or something.

Android Lint deprecated API in:
NavigationDrawerFragment
Utils

As described in GCM docs.

http://developer.android.com/training/volley/index.html

Using WireMock

We probably want to change "fsecure" in it to something else.

If you open for example contacts and then switch back to map view, zoom level and position will be reset to current location

Currently Lokki seems to be quite a heavy battery user. Perhaps possible to optimize by using newer APIs?

The documentation fix #23 is valid for just the current version of the app. There should be a command written without any specific version number, e.g.

$ adb install -r App/build/outputs/apk/lokki-v[VERSION_NUMBER]-debug.apk

Maybe then also leave an example with a concrete version number?
It would also probably be good to add how to find the version number of the build.

Lint reports lots of API level mismatches. current min is 10 but requires level 11
Time to bump up api level?

Add logging or something else?

If the place text is small, it is not intuitive to the user to long press the text.

You are not actually added to your own contacts, but the notification is erroneous.

Currently a contact disappears from the list only when both the user and the other user set off "Can see me"

I'm not sure we should take all possible things that real devices might have into account, but we might want to make a decision about it.

For example, a child could notify his parents that he's arrived where he's supposed to. Lokki would then show a notification/play a sound/vibrate on parent's phone.

Requires changes to backend as well.

Parent can, for example, ask their children where they are. Child's phone would then buzz/play a sound/show a notification.

Since parent should be able to see their child's location always by just opening their own Lokki app, I guess the only (?) use case for this would be when child has forgotten their Lokki to invisible mode.

I think we have two different testing approaches on the table:

• Python & uiautomator bindings, utilizing state_machine_crawler.
• More "standard" Android testing, using Espresso.

Some pros and cons:

state_machine_crawler:
+ Require less changes on state since we don't need to reset the whole application after every test – which should mean faster test execution time.
+ Tests can maybe be smaller and organized better, as we don't have to tell every test what to do before we get to the actual feature we want to test.
+ Since tests are written in Python, we can utilize REPL to help us to write tests.
- We lose the ability to mock Java classes, since this is purely a black box approach.
- Not widely used, so we don't have a lot of resources available. This is probably also a bit off-putting for any potential contributors outside of Software Factory.
- Setup is more complex, since now we're pulling a whole new language in.

Espresso:
+ Can mock Java classes.
+ Seems to be relatively popular.
- Need to do compilation after every change in tests. However, it doesn't require building application APK and installing it every time, so this is not that terrible.
- We need to reset the application state after every test. This was surprisingly fast

So, thoughts? Please comment if you have cons or pros that I missed. Personally I'm leaning towards Espresso since the ability to Mock Java classes directly is pretty powerful (we'll need some kind of solution for faking the HTTP server at least), and seems to be a lot more standard setup compared to the state_machine_crawler.

Until our test suite is actually comprehensive, the long build times on Travis are anyway caused by the missing x86 virtualization and because it has to setup the testing environment and boot the emulator from scratch every time.

There's a lot of AQuery library usage that relies on giving the callback method name as a parameter, so the library can find the function with reflection and call it. This isn't wrong, but lose a lot of static checking this way – for example, the ability to figure out what methods are unused and what are not. So we might want to get rid of them whenever we see them.

Espresso site comments that "To avoid flakiness, we highly recommend that you turn off system animations on the virtual or physical device(s) used for testing" and also links to a way to do it programmatically.

I tried doing this with a slightly different approach (here, found on the comments of disabling animations page), but whatever I did, it refused to work, so I let it to be for now, especially because our test issues didn't seem to be because of this. But now we actually had a case where animations caused tests to fail (on Akira's device), so we might want to look at this more.