Hi,
anonym wrote (25 Nov 2013 19:24:51 GMT) :
> 21/11/13 09:17, intrigeri wrote:
>> I'm concerned about the impact on our test suite: it seems suboptimal
>> to (automatically) test code paths that are different from the ones
>> most users will go through.
> Even if we add a comprehensive cucumber feature that tests all scenarios
> we think matter for both cases (i.e. enabled and disabled)?
This would definitely be better.
However... when we find ourselves in a position when we can base
implementation decisions on "let's have more automated tests", then
I'm happy, but I don't think it would be wise to act as if we were
there yet.
>> IIRC we're setting a kernel cmdline
>> parameter when running the test suite, so perhaps this changing of
>> defaults could be disabled when a testing environment is detected?
> This would be both easy and appropriate, yes.
> Another approach is to change the default only for known problematic VMs
> (currently only VirtualBox), which is made easy since virt-what tells us
> which VM it detects. We this we would *by default* spoof the MAC address
> of Tails in the scenario where someone runs Tails in a e.g.
> libvirt/qeumu with a bridged adapter on a hostile network (it's up to
> the user to then also spoof the much more important *real* MAC address
> of the host computer). A small gain, I suppose.
I agree it's a small gain, compared to the simpler and more robust
(not depending on what specific string virt-what outputs) "don't
change the defaults when a testing environment is detected".
Cheers!
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
