I’ve talked about and shown examples of testing with code (we usually say Unit testing) with fellow developers, but it seems that there is always a barrier to getting started. Here are some of my thoughts on helping you get past that barrier.
Notice that I avoided “Unit testing” in my title.
I break testing with code into several categories, that help me think and talk about testing.
- Functionality of test directly, with dependencies removed through mocks or fakes.
- Behavior (BDD)
- Test the expected behavior of one or more methods
- Think more in lines of the user
- Given x, When x, It Should …
- Automated UI
- Click through UI and verify output
- Selenium to test the UI in Web
- Tests that use real web services, databases, devices, etc. to verify pieces work together
- Test database scripts can help ensure migration happens correctly
- Test full system with multiple pieces end to end to ensure a user action can be completed.
- Memory usage, Load testing
- User Acceptance Testing (edit from Bill Ayers comment)
- This can be automated or manual, but usually a combination of both. The BDD approach and/or User Stories can be helpful for this.
- “The key point about User Acceptance Testing is that it usually is a contractual requirement for customer sign-off and hence payment. This sets it apart from your own system tests in that it is usually the responsibility of the customer. In Agile processes it would be part of the "definition of done".” from Bill’s comment
- Check out the concept of a Deployment Pipeline in the Continuous Delivery book.
- Read the Art of Unit Testing book and watch videos by Roy Osherove.
- Read Test Driven Development by Kent Beck
- Educate yourself on reasons why developers should consider writing code to test code. There are many links, but here is one from Roy Osherove.
- http://www.slideshare.net/dhelper/benefit-from-unit-testing-in-the-real-world (slide 9 -11 especially
- Here are some of my thoughts:
- Continuous Integration and deployment depend on it
- mindset change from developing and putting most of the testing responsibility on QA (devs are responsible for testing before giving it to QA or checking in)
- helps when QA resources and time are lacking, these tests should result in faster manual regression tests
- You don’t have to click through the UI every time you make a change, it’s faster
- You have more confidence when you check in that you aren’t introducing regression bugs.
- Think about testing from the outside in and use Behavior Driven Development principles to define acceptance criteria and behaviors before starting work. (see my post about some benefits of BDD). Build this into your development process and thinking, even into the requirements/acceptance criteria and testing, not an afterthought or they won't get done.
- Write modular code following the SOLID principles and Single Responsibility Principle.
- Use Dependency Injection to inject those dependencies.
- Use a MVVM or MVC pattern for UI (KnockoutJS and AngularJS for web UIs)
- Start with bugs as they come in. Squash them and make sure they don’t come back.
- Determine what areas of your code are the most critical and easiest to test to decide where to start.
- Run your tests in gated check-in builds and nightly builds. Don’t allow a manual test or release until all tests pass.
Useful Hints for Writing Tests
- Comment your tests and think about tests with
- Test Naming: NameOfMethod_ItemOfTest_Expectation
- Usually One test project per project.
- MySite.Data could have MySite.Data.Tests
Use Karma to test on multiple browsers at one time
Use Selenium for web testing instead of CodedUI.
Consider using BrowserStack or SauceLabs to run your tests on their servers, instead of maintaining your own hardware.
Hopefully this helps you get started in the world of writing tests to test your code. Let me know if this was helpful or if you have more suggestions to add to this list!