I have found multiple ways of looking at this:

1. behaviour vs methods

2. behaviour vs state

3. behaviour vs implementation

(1) Unit-Test Behaviour, Not Methods

focus on the features that the object under test should provide,

We need to know how to use the class to achieve a goal, not how to exercise all the paths through its code.

Describing Behavior, Not API Features

We need to know how to use the class to achieve a goal, not how to exercise all the paths through its code.

(src: Book: Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce)

So behaviour here is the protocol, instead of the interface (Model: interface vs protocol)

(2) Test behaviour instead of state

Another way of looking at it, is say 'test behaviour' means

• test the behaviour like a user would use it

• or

• test the system as it would be used

instead of:

@Test cannot_create_duplicate_users() {

// arrange

...

var user = new User("a name")

userRepository.add(user)

 

// act

var secondUser = createUser("a name")

 

// assert

expect(secondUser).toBeNull()

expect(userRepository.users.filter(name ~= "a name")).toBe(user)

}

do this:

@Test cannot_create_duplicate_users() {

// arrange

...

 

// act

createUser("a name")

createUser("a name")

 

// assert

expect(DuplicateUsernameNotAllowed)

}

The first 'tests the implementation'

The second 'tests the behaviour'

With the second, you test the behaviour of the system.

'registering a user with the same name twice is not allowed'

With the first, you test

'if there is already a user with that name, you cannot create another user with that same name'

(3) Test behaviour instead of implementation

I have heard this phrase often.

I have used it occasionally.

But right now, it's still pretty vague to me.