You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Logs snapshot testing for Android Instrumentation tests.
9
+
10
+
## Introduction
11
+
12
+
Similarly to screenshot testing, which is an easy and mantenible approach to ensure your application UI does not get broken, loggerazzi brings the same "snapshoting" idea, but for your analytics or any other application logs.
13
+
14
+
## Usage
15
+
16
+
You just need to include the loggerazzi plugin in yout project, and the rule in your test class (configuring it properly).
17
+
18
+
In order to universally include all your existing application tests, rule can be added to your tests base class.
19
+
20
+
To include the plugin, add plugin classpath to your project build.gradle buildscript dependencies block:
Finally, add Loggerazzi rule to your test class (or base instrumentation tests class), where a logs recorded must be provided (Check configuration section):
50
+
51
+
```kotlin
52
+
openclassBaseInstrumentationTest {
53
+
@get:Rule
54
+
val loggerazziRule:LoggerazziRule=LoggerazziRule(
55
+
recorder = fakeAnalyticsTracker
56
+
)
57
+
}
58
+
```
59
+
60
+
For more details, check included [application example](app).
61
+
62
+
## Execution
63
+
64
+
### Verification mode
65
+
66
+
Regular `connectedXXXXAndroidTest` target invocation is enough for verifications against previosuly generated logs baselines. Android Studio executions should also work seamlessly.
67
+
68
+
```bash
69
+
./gradlew :app:connectedDebugAndroidTest
70
+
```
71
+
72
+
In case of any failures due logs verifications, regular junit reports include failed tests and comparation failure reason.
73
+
74
+
Additionally, an specific loggerazzi report is generated at --> `build/reports/androidTests/connected/debug/loggerazzi/failures.html`
75
+
76
+
### Recording mode
77
+
78
+
When the logs baseline needs to be updated, it's enough to include `-Pandroid.testInstrumentationRunnerArguments.record=true`.
This execution won't perform any logs verification, instead, it will execute tests to generate new logs, placing them in the corresponding tests baseline directory.
85
+
86
+
A loggerazzi report with all recorded logs is generated at --> `build/reports/androidTests/connected/debug/loggerazzi/recorded.html`
87
+
88
+
## Execution from external runners
89
+
90
+
In situations where the regular `connectedXXXXAndroidTest` target is not used because execution is performed by a different external test runner (such as composer or marathon), two loggerazzi gradle tasks are provided which should be executed manually before and after external test runner execution:
91
+
-`loggerazziBefore[VariantName]AndroidTest`
92
+
-`loggerazziAfter[VariantName]AndroidTest`
93
+
94
+
In case test execution is triggered from any gradle task, here's an example on how to configure dependencies with loggerazzi tasks:
Loggerazzi rule must be configured with a [LogsRecorder](loggerazzi/src/main/java/com/telefonica/loggerazzi/LogsRecorder.kt) implementation which will be used by loggerazzi to obtain logs recorded at the end of the test. This should be usually implemented as the replacement of the original application tracker in tests.
By default, loggerazzi rule compares recorded logs by ensuring these are equal and in same order than the baseline logs.
141
+
142
+
In case a different comparation mechanism is needed (such as ignoring the order of the events, or ignoring certain logs), you can implement an specific [LogComparator](loggerazzi/src/main/java/com/telefonica/loggerazzi/LogComparator.kt), which can be provided to the LoggerazziRule on its creation.
0 commit comments