[2222] removed axfr_running checking after starting transferring

As result of the review on #2222, we agreed that that test doesn't make sense.
We can observe increased axfr_running only in a situation that transferring
takes longer than one second. In this lettuce situation, transferring would be
done in shorter than one second. So that test was removed.

diff --git a/tests/lettuce/features/xfrin_notify_handling.feature b/tests/lettuce/features/xfrin_notify_handling.feature
index ffde7b9d346dd8d8d1463173a06cc22719d17766..80a887330157f59ebd23f3ebd31db1401b2dcca3 100644 (file)
--- a/tests/lettuce/features/xfrin_notify_handling.feature
+++ b/tests/lettuce/features/xfrin_notify_handling.feature
@@ -45,14 +45,6 @@ Feature: Xfrin incoming notify handling
     Then wait for new bind10 stderr message AUTH_RECEIVED_NOTIFY
     Then wait for new bind10 stderr message ZONEMGR_RECEIVE_NOTIFY
     Then wait for new bind10 stderr message XFRIN_XFR_TRANSFER_STARTED
-    And when I query statistics axfr_running of bind10 module Xfrout with cmdctl port 47804
-
-    # The counter may or may not have been incremented. Whatever the
-    # server likes. This test should have been actually effective but
-    # the axfr transfering is mostly done in real short time. it is
-    # hardly to observe 'axfr_running' incremented to one.
-    Then the statistics counter axfr_running should be between 0 and 1
-
     Then wait for new bind10 stderr message XFRIN_TRANSFER_SUCCESS not XFRIN_XFR_PROCESS_FAILURE
     Then wait for new bind10 stderr message ZONEMGR_RECEIVE_XFRIN_SUCCESS
     Then wait 5 times for new master stderr message NOTIFY_OUT_SENDING_NOTIFY