Feature #8008: Optimize tests that need a persistent volume

Feature #8008

Optimize tests that need a persistent volume

Added by intrigeri 2014-10-05 10:30:58 . Updated 2015-11-03 11:31:21 .

Status:

Resolved

Priority:

Normal

Assignee:

Category:

Test suite

Target version:

Tails_1.7

Start date:

2014-10-05

Due date:

2016-01-15

% Done:

100%

Feature Branch:

test/6094-improved-snapshots

Type of work:

Code

Blueprint:

Starter:

Affected tool:

Deliverable for:

268

Description

In the feature/apparmor branch, I added three features that need to install Tails, set up persistence, (optionally) copy files to persistence and then do stuff in the system booted from this virtual USB drive with persistence enabled. The setup process takes a long time, and adding more and more similar tests will slow down the test suite even more. We need to find a way to optimize this.

Subtasks

Related issues

Related to Tails - ~~Feature #8004~~: Basic AppArmor support	Resolved	2014-10-05
Related to Tails - ~~Feature #6094~~: Test suite: background snapshot improvements	Resolved		2015-10-15

History

#1 Updated by intrigeri 2014-10-05 10:35:21

Assignee set to anonym
Target version set to Sustainability_M1
QA Check set to Info Needed

Flagging for 2.0, as if we don’t fix this somehow, our test suite will become very hard to run.

anonym, any idea? I’m fine with implementing it, but your deep knowledge of the test suite will likely make you waaay more efficient than me to find a clever solution to this problem. What I’ve thought of:

Move all these tests to a single feature, and set up the needed USB drive only once; the problem is that then, we have tests grouped this way for obscure technical reason, instead of having e.g. all Pidgin tests in pidgin.feature. This is the easiest way forward, but it feels wrong. Worst case, I guess I’ll just do that.
Find a way to set up this storage volume in some early background/before-like scenario, and preserve it so that it can be re-used by all following features. I’m not sure this would be a great design either, and I suspect the implementation would make the test suite way harder to wrap one’s mind around.

#2 Updated by intrigeri 2014-10-06 05:27:08

related to ~~Feature #8004~~: Basic AppArmor support added

#3 Updated by anonym 2014-10-22 16:11:54

related to ~~Feature #6094~~: Test suite: background snapshot improvements added

#4 Updated by anonym 2014-10-22 16:14:12

Status changed from Confirmed to In Progress
QA Check changed from Info Needed to Dev Needed
Type of work changed from Code to Research

intrigeri wrote:
> Flagging for 2.0, as if we don’t fix this somehow, our test suite will become very hard to run.

Agreed. It’s already showing…

> anonym, any idea? I’m fine with implementing it, but your deep knowledge of the test suite will likely make you waaay more efficient than me to find a clever solution to this problem.

I have actually already started some early investigations of this. I’d be happy to take it => updated ticket accordingly.

> What I’ve thought of:
>
> * Move all these tests to a single feature, and set up the needed USB drive only once; the problem is that then, we have tests grouped this way for obscure technical reason, instead of having e.g. all Pidgin tests in pidgin.feature. This is the easiest way forward, but it feels wrong. Worst case, I guess I’ll just do that.

Worst case, yes.

> * Find a way to set up this storage volume in some early background/before-like scenario, and preserve it so that it can be re-used by all following features. I’m not sure this would be a great design either, and I suspect the implementation would make the test suite way harder to wrap one’s mind around.

I’ve posted some thoughts about this into ~~Feature #6094~~. Indeed, I believe whatever we come up with will make the test suite very hard to understand.

#5 Updated by anonym 2015-01-09 13:44:41

Target version changed from Sustainability_M1 to Tails_1.8

#6 Updated by intrigeri 2015-01-09 16:34:18

A strategy could be to implement the solution described in ~~Feature #6094~~ for memory snapshots first, and once happy with it, extend it to also support storage snapshots to address the problem this ticket is about.