Menu
I have been doing a number of tests for developing using TDD; i.e write my test first.
I have always been used to writing the test like so, using this naming convention.
MethodName_DoesWhat_WhenTheseConditions
These work great for unit testing as I am aware of what the method names are, but doing TDD I am not aware of the method names. For example I have a user story that states
"As a user, I can return the total number of records in the database"
Now just taking a look at this, I know straight away that I will have a number of methods, layers.
But I don't know the names of these methods right now in TDD, so does it make sense to try and prefix the test names? Does anyone have any advice here?
Also once I have written my tests and my methods/classes and everything is working does it make sense to create additional "unit tests" to test the class for things I didn't via TDD?
670
What’s the difference between unit testing and TDD? Unit testing is the art of creating automated tests for your code, usually after you have written the code. Test-driven development (TDD) is a set of practices where you write your unit tests before writing your production code and continuously run those tests as you write new code.
As we know Naming standards in any format for anything like ( code, documents, unit test, etc) are always helpful in the long run. The naming standard brings uniformity, avoids ambiguity. Coming to Unit testing naming, however, we don’t really need to get crazy.
Naming standards are important because they explicitly express the intent of the test. Tests are more than just making sure your code works, they also provide documentation. Just by looking at the suite of unit tests, you should be able to infer the behavior of your code without even looking at the code itself.
However you can't do test driven development without using unit tests. When you do traditional unit testing, you write test after you wrote your code. Test driven development approach is to write unit test before writing code. Most interesting advantages of TDD (IMHO) comparing to simple Unit Testing: Code is fully tested code upfront.
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.
97
Given your user story, my test names would be something like:
And the test class would be something like DatabaseRecordCounterTest.
40
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
