Most recent activity
-
Concept: Run smoke tests / unit tests in custom built Espruino IDE docker images with GitHub actions
Hi everyone! I was thinking about the following possible workflow in order to automatically run unit tests or smoke tests in an emulator:
- build a docker image that contains the Espruino IDE (https://espruino.com/ide) or a smaller version of it
- when a commit in a PR gets pushed, this triggers a GitHub action
- optionally the smoke tests could also be run just once a day, e.g. at midnight, to save GitHub Actions minutes
- this GitHub action uses the Espruino IDE docker image and automatically loads the newly added/changed code in the IDE
- some test cases that check basic functionality of the app run and confirm the changes don't break other code
When it comes to test cases, obviously some mocking needs to be done, however I think this is perfectly doable. For example https://www.espruino.com/ReferenceBANGLEJS2#l_E_getTemperature always returns
NaN
in the emulator, but the easiest way to mock it for the test suite would be to callE.getTemperature = function() { return 20; };
at the start of the test suite.For example, here's some pseudo code I came up with for
activityreminder
:// Suite setup // Mock some functions E.getTemperature = function() { return 27; }; // assume the user is always wearing the smart watch settings.maxInnactivityMin = 0; // immediately trigger an inactivity warning by setting max inactivity to 0 min // Test cases // wait a few seconds and assert E.showPrompt() got called (which should happen) // if not, fail the test or raise a warning // (optionally) take a screenshot and include it as an artifact
Why would this be useful?
Around 2 weeks ago there was an issue where (if I understood correctly) some firmware changes caused a new date format which brokeactivityreminder
because it still expected/used the old date format. We could detect sudden breaking changes like this one using test cases. For example, the test case above would have failed after the new date format changes, because it couldn't have read the new date format.Obviously this is a huge suggestion and is probably low priority, but I'm just sharing my ideas and I'm open for feedback! What are your thoughts about this?
- build a docker image that contains the Espruino IDE (https://espruino.com/ide) or a smaller version of it
-
-
-
You can calculate the RMSSD using the differences in ms between heartbeats like this:
function calculateRMSSD(RRIntervals) { var sumOfDifferencesSquared = 0; for (var i = 0; i < RRIntervals.length - 1; i++) { var difference = RRIntervals[i + 1] - RRIntervals[i]; sumOfDifferencesSquared += difference * difference; } var meanSquaredDifference = sumOfDifferencesSquared / (RRIntervals.length - 1); var rmssd = Math.sqrt(meanSquaredDifference); return rmssd; }
This is one of many ways to calculate the stress level. The event Bangle.HRM only gives the current heart beat calculated, however, the event doesn't get fired at exactly the time when a heartbeat was recognized.
I know there is a
.raw
property that provides raw data by the sensor, which you could use to manually replicate the algorithm that measures when individual heart beats occurred, however I believe this procedure is kind of reinventing the wheel.I'm pretty sure the data about the individual time differences between heart beats already exists somewhere because otherwise the algorithm couldn't calculate the heart beat.
So, how do I get the differences between individual heart beats? Thanks.
-
Thanks everyone!
I guess one could also make the assumption that at times with lots of app switching you probably are not doing a lot of moving around. So it probably wouldn't impact the statistics too much doing without retaining info across resets/loads.
Yes, that's probably true, so to save CPU and battery usage, I'll probably ignore App switches and not save data to storage, and assume that no significant activity was done during that time.
Thanks for the info. If this already exists, cool, no need to build any new images then. And yes, I get the point that automatically catching and uploading errors would definitely be a problem regarding privacy.