-
Notifications
You must be signed in to change notification settings - Fork 205
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
[WIP] Add maze harness #246
Conversation
…-android into add-maze-harness
Pull Request Test Coverage Report for Build 1247
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, I'd make a few structural changes to better indicate what the new files are for. Both fakekeys.jks
and mazerunner/
should be in features/fixtures/
since these files only exist for the sake of running the feature/
tests.
Gemfile
Outdated
@@ -0,0 +1,4 @@ | |||
source "https://rubygems.org" | |||
|
|||
gem 'bugsnag-maze-runner', path: '../../..' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'll need to swap this with the git path:
- gem 'bugsnag-maze-runner', path: '../../..'
+ gem 'bugsnag-maze-runner', git: 'git@github.com:bugsnag/maze-runner'
@@ -1 +1 @@ | |||
include ':example', ':testharness', ':sdk', ':examplelib' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The maze is likely to get pretty big. I'd think we wouldn't want to build/test it by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Running ./gradlew clean :mazerunner:assemble --profile
currently completes in ~15s. I'd agree that we should keep an eye on how long it takes to build as we add more scenarios, but think that there's currently still a benefit to building this on CI as it will detect any compilation errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On CI, sure. I thought it was odd/long to run gradle build
locally and automatically run the examples.
Started merging these down so the larger changes make sense, but may have caused some conflicts as the test scenario generation signature seems to have changed and I'm not sure which one is right. |
Resolved the Scenario signature update to include the config + context (which allows for initialising Bugsnag with our own params before each scenario starts). Other comments still need to be addressed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quick summary now that everything is merged up:
- All scenarios should have names describing exactly what is being tested, i.e. "Attaching metadata to a report from a global callback"
- Related scenarios should be merged into features "Reporting handled exceptions", "Filtering metadata", "Session tracking", "Reporting unhandled exceptions", "Release stages", "Recording user information", etc
- Test-only projects and files should be moved out of the root of the repository into
features/fixtures
I have grouped the scenarios together which I thought made sense, it'd be good to confirm there aren't any others that would fit together. I've also moved the test files into |
features/breadcrumb.feature
Outdated
@@ -0,0 +1,18 @@ | |||
Feature: Reporting Breadcrumbs | |||
|
|||
Scenario: Test handled Android Exception |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing a scenario name here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to "Manually added breadcrumbs are sent in report"
features/filtering_metadata.feature
Outdated
And the event "metaData.custom.password" equals "[FILTERED]" | ||
And the event "metaData.user.password" equals "[FILTERED]" | ||
|
||
Scenario: Manual Filter Tracking |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is manual filter tracking? Adding a custom metadata filter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a much better name - I've updated the scenario title.
And the request is a valid for the error reporting API | ||
And the exception "errorClass" equals "android.os.StrictMode$StrictModeViolation" | ||
And the exception "message" equals "policy=262148 violation=4" | ||
And the event "metaData.StrictMode.Violation" equals "NetworkOperation" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I occasionally get this:
Scenario: StrictMode Network on Main Thread violation # features/strict_mode.feature:12
When I run "StrictModeNetworkScenario" with the defaults # features/steps/build_steps.rb:1
Then I should receive a request # maze-runner-65bdcb7a135e/lib/features/steps/request_assertion_steps.rb:11
And the request is a valid for the error reporting API # maze-runner-65bdcb7a135e/lib/features/steps/error_reporting_steps.rb:1
the field 'events' must be a non-empty array (Minitest::Assertion)
features/strict_mode.feature:15:in `And the request is a valid for the error reporting API'
And the exception "errorClass" equals "android.os.StrictMode$StrictModeViolation" # maze-runner-65bdcb7a135e/lib/features/steps/error_reporting_steps.rb:47
And the exception "message" equals "policy=262148 violation=4" # maze-runner-65bdcb7a135e/lib/features/steps/error_reporting_steps.rb:47
And the event "metaData.StrictMode.Violation" equals "NetworkOperation" # maze-runner-65bdcb7a135e/lib/features/steps/error_reporting_steps.rb:25
Request output:
URI: http://10.0.2.2:9291/
HEADERS:
content-type: 'application/json'
bugsnag-sent-at: '2018-03-15T10:40:21Z'
bugsnag-api-key: 'a35a2a72bd230ac0aa0f52715bbdc6aa'
bugsnag-payload-version: '4.0'
user-agent: 'Dalvik/2.1.0 (Linux; U; Android 7.0; Android SDK built for x86_64 Build/NYC)'
host: '10.0.2.2:9291'
connection: 'Keep-Alive'
accept-encoding: 'gzip'
BODY:
{
"apiKey": "a35a2a72bd230ac0aa0f52715bbdc6aa",
"payloadVersion": "4.0",
"notifier": {
"name": "Android Bugsnag Notifier",
"version": "4.3.1",
"url": "https://bugsnag.com"
},
"events": [
]
}
Any idea what's going on here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, not 100% sure, but could this be another manifestation of #270? If the errorFile is deleted prior to request serialisation then an empty array of events would be expected. Is only 1 request received by this scenario?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I tried running this around 5 times and it seemed to pass consistently on my setup)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to be inconsistent and could potentially be related to #270 - there seems to exist a case where the payload is sent but no events are present.
@kattrali are there any further actions on this one? I've been unable to reproduce the StrictMode issue. |
Increase test matrix for E2E scenarios
feat (NativeInterface): add SetAutoDetectAnrs method to Bugsnag interface
Adds a harnessed app for Maze Runner, and removes the old test harness module.
This also adds the boilerplate required to launch a test scenario that sends a payload.