Browse Source

[master] Check for nonexistent db right after BIND starts

Mukund Sivaraman 13 years ago
parent
commit
9a93486052
1 changed files with 6 additions and 6 deletions
  1. 6 6
      tests/lettuce/features/example.feature

+ 6 - 6
tests/lettuce/features/example.feature

@@ -5,7 +5,7 @@ Feature: Example feature
     is intentionally uncommented.
     The later scenarios have comments to show what the test steps do and
     support
-    
+
     Scenario: A simple example
         Given I have bind10 running with configuration example.org.config
         And wait for bind10 stderr message BIND10_STARTED_CC
@@ -29,7 +29,7 @@ Feature: Example feature
         # Underwater, we take advantage of our intialization routines so
         # that we are sure this file does not exist, see
         # features/terrain/terrain.py
-        
+
         # Standard check to test (non-)existence of a file
         # This file is actually automatically
         The file data/test_nonexistent_db.sqlite3 should not exist
@@ -43,6 +43,9 @@ Feature: Example feature
         And wait for bind10 stderr message CMDCTL_STARTED
         And wait for bind10 stderr message AUTH_SERVER_STARTED
 
+        # Now we use the first step again to see if the file has been created
+        The file data/test_nonexistent_db.sqlite3 should exist
+
         bind10 module Auth should be running
         And bind10 module Resolver should not be running
         And bind10 module Xfrout should not be running
@@ -56,16 +59,13 @@ Feature: Example feature
         # use in the start step (for bind 10, that is 'I start bind10 with')
         # See scenario 'Multiple instances' for more.
         Then stop process bind10
-        
-        # Now we use the first step again to see if the file has been created
-        The file data/test_nonexistent_db.sqlite3 should exist
 
     Scenario: example.org queries
         # This scenario performs a number of queries and inspects the results
         # Simple queries have already been show, but after we have sent a query,
         # we can also do more extensive checks on the result.
         # See querying.py for more information on these steps.
-        
+
         # note: lettuce can group similar checks by using tables, but we
         # intentionally do not make use of that here