Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend testing frameworks #99

Closed
dkhmelenko opened this issue Feb 11, 2016 · 6 comments
Closed

Extend testing frameworks #99

dkhmelenko opened this issue Feb 11, 2016 · 6 comments

Comments

@dkhmelenko
Copy link

Would be nice to have a section with best practices for using unit testing frameworks (JUnit, Mockito)

@peter-tackage
Copy link
Contributor

Agreed @Brave-Warrior. This has been on my backlog for a while as the landscape has certainly changed since the initial version of this document.

@peter-tackage
Copy link
Contributor

As a brief summary of my thoughts how to write tests:

  • Minimize explicit Android dependencies in your code through abstraction and separation of concerns. Android dependencies require you to use instrumentation tests, which are considerably slower than strictly Java (JVM) based tests.
  • Start with unit tests, driven by JUnit4.
  • Use Mockito for mock definitions
  • Use descriptive names for the unit test to aid in defining expected behavior.
  • Use good test structure: Arrange, Act, Assert.
  • Separate arrangement definitions into an "arrange builder" to improve test readability.
  • Use AssertJ for assertions.
  • Add integration and UI tests once their business value is justified.
  • Use PowerMock for mocking statics and final classes as a last resort.
  • Be aware that pure Java unit testing has its limits, and that writing specific Android tests still remains important in some cases - for example; database handling.

@tomaszpolanski might have some input here too.

@tomaszpolanski
Copy link

When using Rx and "scheduled" observable, either inject schedulers or something that provides them.
Then in test you can use TestScheduler to test timer related functionality.

@dkhmelenko
Copy link
Author

@peter-tackage agree with your points. But would extend the following items with the links to appropriate resources or detailed description:

  • Use Mockito for mock definitions

add link for Mockito; the recommendations how to mock objects and the check behaviour in the better/best way

  • Use AssertJ for assertions.

Link to AssertJ would be good and what are the advantages of that

  • Add integration and UI tests once their business value is justified.

not clear enough

The other points are quite clear and could be added to the best practices.

@peter-tackage
Copy link
Contributor

@tomaszpolanski Agreed. Testing Rx is probably worth it's own section.

@peter-tackage
Copy link
Contributor

@Brave-Warrior I'll be progressing the testing section update under #114

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants