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
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
The text was updated successfully, but these errors were encountered:
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.
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
The text was updated successfully, but these errors were encountered: