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
This is just an idea, opening for discussion @zvin. Right now, for PRs like #25, I need to manually edit the images, creating partitions that simulate real images, but which stay small, because we have to commit them.
We could change this, so that:
When you run the test, it downloads some set of real images, if you don't already have them locally
When you need to write an image, we generate an empty file, rather than having to have a device.random file that has exactly the same file as every image.
That way the git history would be tiny, we wouldn't have to manually mess around with images, and while the first test run would take a while, all later runs would be pretty quick.
More importantly, imo, this would make our tests totally representative of real usage. Right now, it's hard to be sure device init works on a real image, so I've mostly been testing by linking this module into the CLI. If we were really running them against real images, we'd have actual guarantees.
What do you think?
The text was updated successfully, but these errors were encountered:
That sounds good.
The only problem is that will require Internet access for running tests. resin-device-init tests already require it anyway.
I'll need something similar for testing resin-preload.
We can get the images from the staging image-maker s3 bucket, it requires no credentials.
This is just an idea, opening for discussion @zvin. Right now, for PRs like #25, I need to manually edit the images, creating partitions that simulate real images, but which stay small, because we have to commit them.
We could change this, so that:
device.random
file that has exactly the same file as every image.That way the git history would be tiny, we wouldn't have to manually mess around with images, and while the first test run would take a while, all later runs would be pretty quick.
More importantly, imo, this would make our tests totally representative of real usage. Right now, it's hard to be sure device init works on a real image, so I've mostly been testing by linking this module into the CLI. If we were really running them against real images, we'd have actual guarantees.
What do you think?
The text was updated successfully, but these errors were encountered: