Return to Answer

By following an "Outside-In" development approach you would discover/evolve your TDD unit test names as part of the development process (also see this answer here)

For example take your user story (I've slightly amended it):

As a user
I want to know the total number of records in the database
So that I can report back to the business owner

When developing this story would would break it down into a number of scenarios e.g.

Given a user logs in
When they request the total number of records
Then they should be presented with the result

At this stage you still don't know what unit tests you would need. However, using the "Outside-In" development approach you would now revert to TDD techniques to implement the necessary functionality.

For example you would next implement the log-in facility using your normal TDD approach. Hence you might have a test method called:

WhenSubmitValidCredentialsShouldBeAuthorised

You can also "fake it until you make it" using this approach i.e. you can mock certain dependencies (e.g. the authorisation mechanism) so that you can focus on implementing the key features of the scenario.

So following this approach you would incrementally develop all of the functionality required for your User Story whilst creating the exact unit tests to satisfy the scenarios.

By following an "Outside-In" development approach you would discover/evolve your TDD unit test names as part of the development process (also see this answer here)

For example take your user story (I've slightly amended it):

As a user
I want to know the total number of records in the database
So that I can report back to the business owner

When developing this story you would break it down into a number of scenarios e.g.

Given a user logs in
When they request the total number of records
Then they should be presented with the result

At this stage you still don't know what unit tests you would need. However, using the "Outside-In" development approach you would now revert to TDD techniques to implement the necessary functionality.

For example you would next implement the log-in facility using your normal TDD approach. Hence you might have a test method called:

WhenSubmitValidCredentials_ShouldBeAuthorised

You can also "fake it until you make it" using this approach i.e. you can mock certain dependencies (e.g. the authorisation mechanism) so that you can focus on implementing the key features of the scenario.

So following this approach you would incrementally develop all of the functionality required for your User Story whilst creating the exact unit tests to satisfy the scenarios.

By following an "Outside-In" development approach you would discover/evolve your TDD unit test names as part of the development process (also see this answer here)

For example take your user story (I've slightly amended it):

As a user
I want to know the total number of records in the database
So that I can report back to the business owner

When developing this story would would break it down into a number of scenarios e.g.

Given a user logs in
When they request the total number of records
Then they should be presented with the result

At this stage you still don't know what unit tests you would need. However, using the "Outside-In" development approach you would now revert to TDD techniques to implement the necessary functionality.

For example you would next implement the log-in facility using your normal TDD approach. Hence you might have a test method called:

WhenSubmitValidCredentialsShouldBeAuthorised

You can also "fake it until you make it" using this approach i.e. you can mock certain dependencies (e.g. the authorisation mechanism) so that you can focus on implementing the key features of the scenario.

So following this approach you would incrementally develop all of the functionality required for your User Story whilst creating the exact unit tests to satisfy the scenarios.

By following an "Outside-In" development approach you would discover/evolve your TDD unit test names as part of the development process (also see this answer here)

For example take your user story (I've slightly amended it):

As a user
I want to know the total number of records in the database
So that I can report back to the business owner

When developing this story would would break it down into a number of scenarios e.g.

Given a user logs in
When they request the total number of records
Then they should be presented with the result

At this stage you still don't know what unit tests you would need. However, using the "Outside-In" development approach you would now revert to TDD techniques to implement the necessary functionality.

For example you would next implement the log-in facility using your normal TDD approach. Hence you might have a test method called:

WhenSubmitValidCredentialsShouldBeAuthorised

You can also "fake it until you make it" using this approach i.e. you can mock certain dependencies (e.g. the authorisation mechanism) so that you can focus on implementing the key features of the scenario.

So following this approach you would incrementally develop all of the functionality required for your User Story whilst creating the exact unit tests to satisfy the scenarios.

By following an "Outside-In" development approach you would discover/evolve your TDD unit test names as part of the development process (see this answer here)

For example you have the user story (I've slightly amended your story):

As a user
I want to know the total number of records in the database
So that I can report back to the business owner

When developing this story would would break it down into a number of scenarios e.g.

Given a user logs in
When they request the total number of records
Then they should be presented with the result

At this stage you still don't know what unit tests you would need. However, using the "Outside-In" development approach you would now revert to TDD techniques to implement the necessary functionality.

For example you would next implement the log-in facility using your normal TDD approach. Hence you might have a test method called:

WhenSubmitValidCredentialsShouldBeAuthorised

You can also "fake it until you make it" using this approach i.e. you can mock certain dependencies (e.g. the authorisation mechanism) so that you can focus on implementing the key features of the scenario.

By following an "Outside-In" development approach you would discover/evolve your TDD unit test names as part of the development process (also see this answer here)

For example take your user story (I've slightly amended it):

As a user
I want to know the total number of records in the database
So that I can report back to the business owner

When developing this story would would break it down into a number of scenarios e.g.

Given a user logs in
When they request the total number of records
Then they should be presented with the result

At this stage you still don't know what unit tests you would need. However, using the "Outside-In" development approach you would now revert to TDD techniques to implement the necessary functionality.

For example you would next implement the log-in facility using your normal TDD approach. Hence you might have a test method called:

WhenSubmitValidCredentialsShouldBeAuthorised

You can also "fake it until you make it" using this approach i.e. you can mock certain dependencies (e.g. the authorisation mechanism) so that you can focus on implementing the key features of the scenario.

So following this approach you would incrementally develop all of the functionality required for your User Story whilst creating the exact unit tests to satisfy the scenarios.