Project

General

Profile

Bug #9557

Feature #8543: Write regression tests and tests for new features

Write regression test for the hardware clock not being saved

Added by anonym over 4 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Test suite
Target version:
Start date:
06/10/2015
Due date:
% Done:

100%

Feature Branch:
kytv:test/9557-hwclock
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

That is, check that #9364 remains fixed, e.g.:

--- a/features/time_syncing.feature
+++ b/features/time_syncing.feature
@@ -32,6 +32,12 @@ Feature: Time syncing
     And Tor is ready
     Then Tails clock is less than 5 minutes incorrect

+  Scenario: The system time is not synced to the hardware clock
+    When I bump the system time with "+1 day" 
+    And I warm reboot the computer
+    And the computer reboots Tails
+    Then the hardware clock is still the same as the host's time
+
 #  Scenario: Clock vs Tor consensus' valid-{after,until} etc.

   Scenario: Create a new snapshot to the same state (w.r.t. Sikuli steps) as the Background except we're now in bridge mode

Tip: hwclock -r can be used to query the hardware clock from within Tails in the the hardware clock is still the same as the host's time step (bonus points for a better name that doesn't refer to the "host"). Then it should be compared to the host's clock +/- some seconds.


Related issues

Related to Tails - Bug #9364: Do not set the hardware clock to the system time on shutdown Resolved

Associated revisions

Revision 6efba81d
Added by intrigeri over 4 years ago

Merge remote-tracking branch 'kytv/test/9557-hwclock' into stable

Fix-committed: #9557

Revision 07ad1b43
Added by intrigeri over 4 years ago

Merge remote-tracking branch 'kytv/test/9557-hwclock' into devel

Fix-committed: #9557

History

#1 Updated by anonym over 4 years ago

  • Related to Bug #9364: Do not set the hardware clock to the system time on shutdown added

#2 Updated by anonym over 4 years ago

  • Assignee set to kytv
  • Target version set to Tails_1.4.1
  • Parent task set to #8543

kytv, do you think you can manage this for Tails 1.4.1? Otherwise, please un/re-parent and set a new milestone.

#4 Updated by anonym over 4 years ago

I think we need an anti-test too: verifying that if we change the hardware clock, do a warm reboot, then the hardware clock change remains (modulo the time spent on rebooting).

#5 Updated by intrigeri over 4 years ago

I think we need an anti-test too: verifying that if we change the hardware clock, do a warm reboot, then the hardware clock change remains (modulo the time spent on rebooting).

Yes, this would be ideal. Not sure if libvirt/QEMU give us the means to do that, though. We'll see :)

#6 Updated by anonym over 4 years ago

intrigeri wrote:

I think we need an anti-test too: verifying that if we change the hardware clock, do a warm reboot, then the hardware clock change remains (modulo the time spent on rebooting).

Yes, this would be ideal. Not sure if libvirt/QEMU give us the means to do that, though. We'll see :)

As in "there's no way to query the hardware clock state directly via Libvirt"? That's probably true, but we can do it the same way we do the real test, with hwclock -r. Something like:

  Scenario: Anti-test: the hardware clock is kept after reboot
    When I bump the hardware clock with "+1234 day" 
    And I cold reboot the computer
    And the computer reboots Tails
    Then the hardware clock is still the same as the host's time +1234 days

#7 Updated by kytv over 4 years ago

anonym wrote:

kytv, do you think you can manage this for Tails 1.4.1? Otherwise, please un/re-parent and set a new milestone.

I'll try but if not it should be ready just after 1.4.1.

Setting the hwclock and systime are working as expected. Now I just have to translate what I've done to ruby...

#8 Updated by kytv over 4 years ago

  • Status changed from Confirmed to In Progress
  • Assignee changed from kytv to anonym
  • QA Check set to Ready for QA
  • Feature Branch set to kytv:test/9557-hwclock

I think this branch tests what it is supposed to.

#9 Updated by intrigeri over 4 years ago

  • Assignee changed from anonym to intrigeri

#10 Updated by intrigeri over 4 years ago

  • Assignee changed from intrigeri to kytv
  • % Done changed from 0 to 50
  • QA Check changed from Ready for QA to Dev Needed

OK, so conceptually everything seems fine, yay :)

Here are some comments on the actual implementation.

hwclock_time_str = @vm.execute('hwclock -r').stdout.chomp

Why not execute_successfully?

Then /^the hardware clock was not updated when Tails shut down$/ do

  • Why isn't this step skipped when restoring background snapshots?
  • This step's phrasing doesn't really reflect what it actually does, that is comparing the host system's clock with the system under testing's hardware clock; I suggest rephrasing it to something like "Tails hardware clock is close to the host system's one" (or what anonym proposed initially).

I bump the hardware clock's time with

This duplicates most of I bump the system time with => please refactor.

Also, please don't use date + parsing to get the host system's time: we have Time.now: see examples in Tails clock is less than...

#11 Updated by kytv over 4 years ago

  • Assignee changed from kytv to intrigeri
  • QA Check changed from Dev Needed to Ready for QA

Changes pushed.

#12 Updated by intrigeri over 4 years ago

  • Status changed from In Progress to Fix committed
  • Assignee deleted (intrigeri)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

Yay! Merged locally into stable. Cannot push since my local stable branch is being used to prepare the release, and in its current state I'm not sure what it's worth.

#15 Updated by intrigeri over 4 years ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF