Testing
We’re almost there! It’s been a long way and it’s almost time to celebrate your graduation from the Console Apps area. But there’s one final step: Unit Tests.
More likely than not (and hopefully) the organisation you’ll work will have systems that use automated testing. They make sure everything is running properly before each deployment. The code covered by those tests won’t need to be tested manually every time a change is made, which is prone to errors and very expensive. A strong suite of tests helps developers code that's more maintainable and reliable. So let's jump into it!
Requirements
In this project, you'll create tests for the PhoneBook App, the second project in the course.
You'll need to create a PhoneBook.UnitTests project and a PhoneBook.IntegrationTests project, all under the same solution as the Phonebook app.
Your unit tests should test at least the input validation methods, making sure the app correctly prevents the user from inserting incorrect data.
Your integration tests cannot use InMemoryDatabase, as it doesn't mimick the behavior of a SQL database correctly. If your project uses SQL Server, using SQLite for the tests is still acceptable
You can user whatever testing library you want. The most popular are NUnit and Xunit.
You should test both correct and incorrect inputs.
Include a README with instructions on how to run the project, what the app does, how it works, and your architectural choices. Most importantly, include clear setup and run instructions and a reflection on your development experience, written in your own words.
Resources
Here are a few resources that might be helpful.
Tips
Naming your tests properly is almost as important as writing them. Make sure your tests express their intent clearly as they serve as documentation. Don't be afraid of being verbose. "WhenQuantityInputIsPositive_DataIsPersistedCorrectly" is a good name, while "QuantityTest" doesn't have enough information.
In your test, you'll have to mock the tested service and call it's methods. Think of all possibilities of correct and incorrect inputs and test if the application handles them.
Mocking dependencies in integration testing can be very frustrating. If you're struggling to create testable methods, try breaking them down so they do only one thing. That's the best way to make your code more testable and maintanable.
Sometimes it's good to create one method that runs all tests for a specific functionality. This way you can be sure that all edge cases are covered without having to run each test individually.
Challenges
From now on you'll be required to write tests in many projects. To get a bit more practice before moving on, try going back and writing tests for more apps. The Shifts Logger and the Document Processor could be significantly enhanced with a good testing suite.
Comments
0 comments
No comments yet. Start the conversation.