1. 17 Nov, 2020 1 commit
  2. 02 Nov, 2020 1 commit
    • anonym's avatar
      Test suite: implement find_any() with real_find(). · d186e198
      anonym authored
      We recently bumped the timeout in find() from 2 to 5 seconds (in !218
      for #17985) which made me notice that it's not very appropriate to
      call find() in find_any() and related functions since that timeout
      makes us block very long on each image before moving on to the next.
      I saw an instance where we use find_any() on five images with a 20
      second timeout. This makes it impossible to match the fifth image
      since we'll spend 4*5 = 20 seconds on the first four images and thus
      timeout before we even try the fifth. Ouch!
  3. 28 Oct, 2020 1 commit
    • intrigeri's avatar
      Test suite: don't let Screen#find mess with Screen#wait_vanish's timeout argument · d369bb1c
      intrigeri authored
      7fe21236, and later
      d019aa38, by adding an implicit waiting delay in
      Screen#find, made the semantics of the timeout of Screen#wait_vanish buggy: if
      that timeout is too small compared to the duration of that implicit waiting
      delay, then the timeout of the try_for loop in Screen#wait_vanish will expire
      without having actually tried enough times, effectively making the timeout
      passed to wait_vanish moot.
      For example, at d019aa38,
      this step:
        I do not see "TorBrowserSynapticManual.png" after at most 5 seconds
      … often fails, because Screen#wait is called only once, very early,
      and at that time TorBrowserSynapticManual.png is still on the screen.
      That image disappears quickly, but given the 2 timeouts have the same value
      (5 seconds), we don't even try a second time.
      So let's bypass Screen#find in Screen#wait_vanish, and instead call
      Screen#wait directly with timeout=0.
  4. 27 Oct, 2020 1 commit
  5. 26 Oct, 2020 1 commit
  6. 15 Oct, 2020 1 commit
  7. 19 Sep, 2020 1 commit
  8. 18 Sep, 2020 9 commits
  9. 04 Sep, 2020 1 commit
  10. 02 Sep, 2020 1 commit
  11. 25 Jun, 2020 1 commit
  12. 19 May, 2020 1 commit
    • anonym's avatar
      Revert "Rubocop: manually fix Lint/InheritException offenses" · ab6e0010
      anonym authored
      This reverts commit 794bb06d.
      The reverted change might be what makes try_for() sometimes fail to
      notice when it should time out, resulting in crazy things like:
          try_for: attempt 288 (3586.91s elapsed of 300s)...
      where Jenkins will abort the test due to inactivity.
  13. 12 May, 2020 1 commit
    • intrigeri's avatar
      Test suite: fix regression on Stretch introduced earlier on this branch · 83a6c49b
      intrigeri authored
      Fixup against 4efe5283.
      Interestingly, I did not have this problem with Ruby 2.7.1 on my system,
      but on Jenkins (Ruby 2.3.3) I see this error:
        wrong argument type String (expected Symbol) (TypeError)
        ./features/step_definitions/pidgin.rb:113:in `/^my XMPP friend goes online( and joins the multi-user chat)?$/'
      Until we require Buster for running our test suite, the current implementation
      is rather ugly, but I figured it's better to have an ugly backwards
      compatibility workaround than to stick with old arguments passing style: it
      brings us one step closer to Ruby best practices.
  14. 11 May, 2020 12 commits
  15. 10 May, 2020 7 commits
    • intrigeri's avatar
    • intrigeri's avatar
      Test suite: review and adjust every blind rescue · 36d0aa8b
      intrigeri authored
      As per https://rubystyle.guide/#too-many-params, rescuing the Exception
      class traps signals. We do this quite a bit, which might explain
      why a simple CTRL-c is often not sufficient to kill the test suite.
       - In most cases, our exception handling code does not feel safe enough when
         we're facing a ctrl-c or another system-level exception (think ENOSPAC), i.e.
         we can't be sure it'll manage to rethrow the exception, I've replaced
         "rescue Exception" with "rescue StandardError".
       - In a few cases, the exception handling code was really specific to a given
         "raise" we wrote ourselves, and we're using exceptions raising/rescuing as
         our own control flow mechanism (test fails ⇒ raise), so I'm switching to
         dedicated exception classes in order to rescue only what we want, and no
         other unexpected Exception.
       - In some cases, we have fine-grained custom exception handling, including
         comments about "all other exceptions", so to make things extra clear I'm
         rescuing Exception separately from StandardError in those cases; this should
         highlight the different intended behaviors.
      Note that at first glance, the exception handling code that runs
      destroy_and_undefine looks useful even when aborting with SIGTERM.
      Thankfully, our at_exit handler runs it too, so there's no need
      to _also_ run it in the exception handlers.
      Finally, enable the Lint/RescueException Rubocop check: once we run Rubocop as
      part of our CI, this should avoid us (possibly me!) typing "rescue Exception"
      without being fully conscious of what it really catches.
    • intrigeri's avatar
      Rubocop: enable Metrics/ClassLength · 4884247d
      intrigeri authored
      … with a pretty relaxed maximum value (twice the default), and dropping the ball
      on the worst offender for now.
    • intrigeri's avatar
    • intrigeri's avatar
    • intrigeri's avatar
      Rubocop: enable Metrics/MethodLength · 0a12c656
      intrigeri authored
      … with pretty relaxed maximum values, and dropping the ball on the few worst
      offenders for now. There's lots of room for improvement here, wrt. making pieces
      of code easier to fit into one's brain.
    • intrigeri's avatar
      Rubocop: enable Metrics/AbcSize · cb24a33c
      intrigeri authored
      … with a pretty relaxed maximum value (double of the default), and dropping the
      ball on the few worst offenders for now. There's lots of room for improvement
      here, wrt. making pieces of code easier to fit into one's brain.