Domanda

When using factories, although more work is required up front, you know that you will be setting the correct pre-conditions for your test (up to what you have written.) However, when you use fixtures, although no work is required to setup the database state, someone (including the developer of the test) could easily change the fixtures by accident in some way in the future and render the test useless (e.g. make it always pass no matter what!)

How should a develop guard against this to protect the integrity of the test in the future? Should the pre-conditions be asserted before the test runs? Is this considered best practice?

È stato utile?

Soluzione

If a specific property of the environment is important for that test, then yes, do verify that precondition directly in the test. In particular, this is helpful when the system under tests performs a kind of state transition.

For example, I am writing a user account management system. I want to test that I can add new users. In order to test whether a new user has been created, it makes sense to ensure the user didn't exist previously. E.g. expressed in Cucumber notation:

Scenario: adding a new user
  Given I have an account management system
    And no user named "Fred" exists
   When I add a user named "Fred"
   Then a user named "Fred" exists

or more xUnit-ly:

void test_addingANewUser() {
  assertNull(accounts.getUserByName("Fred"));

  accounts.createUser("Fred");

  assertNotNull(accounts.getUserByName("Fred"));
}

I think verifying these preconditions is a perfectly clear thing to do, regardless of how you create the system state prior to the test. Without this precondition, the test case is incomplete and depends on some setup code for the full details. With this precondition, the test is more self-contained and thus more maintainable.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
scroll top