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

Record some test databases, and build tests for sample processing #21

Open
3 tasks
sobri909 opened this issue Jun 24, 2018 · 1 comment
Open
3 tasks
Assignees

Comments

@sobri909
Copy link
Owner

sobri909 commented Jun 24, 2018

Quoting myself from #20:

So far I've found automated testing to be effectively impossible for the core "ActivityBrain" engine, due to the requirement of a steady flow of CoreLocation and CoreMotion data inputs, where the timing of the inputs is significant. If it's not receiving inputs with effectively real world timings and values, there's very little point in testing it at all. The tests simply wouldn't be useful.

But what can be tested is the results of the timeline processing engine(s) (TimelineProcessor et al). So the plan is to record one or more sessions, with several hours of travel + stationary data, then keep those as "test databases". That will allow processing to be repeatedly run over the same data, and tested for desirable results.

Todos

  • Ability to export a recorded time range from the Demo App
  • Ability to store the raw CLLocation and CoreMotion data in the db
  • Convenience methods for reprocessing a provided database
@sobri909 sobri909 self-assigned this Jun 24, 2018
@sobri909
Copy link
Owner Author

sobri909 commented Jun 24, 2018

Another possibility is to also save the raw CLLocations and CoreMotion input objects to the database, purely for testing purposes.

Aside: Storing the raw input data during normal operation would be a bad idea, because even just a single hour of recording can include tens of thousands of raw data objects (for example the accelerometer data at 5Hz).

Building testing infrastructure for replaying that raw data would be nightmarish, and would require creating an unrealistic environment in the process. So I don't plan to do that. But having a record of that raw data would help with debugging various low level issues, to determine why the ActivityBrain made various decisions in various cases.

A case that comes to mind is underground train trips. Raw data is extremely sparse during underground train trips, to the point where there is usually little to no location data available. The subtle differences in how the CoreMotion data is interpreted in context of the lack of location data can create unexpected and undesirable results.

Being able to pick through the exact raw data for the moment where an incorrect decision was made on such a trip would be very helpful.

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

1 participant