An Introduction to unit testing
Download as PPTX, PDF0 likes2,674 views
This document provides an introduction to unit testing. It discusses what should and should not be tested, how to structure tests using the Arrange Act Assert pattern, and tips for writing good tests. Some key points covered include testing complex code, edge cases, classes that change often, and avoiding testing globals, statics, and database interactions. The goal is to have tests that are independent, test single behaviors, and help find bugs when code changes.
![How to structure a test?
Arrange Act Assert: a sample…
[TestMethod]
public void RegisterWithValidInputs_SendsEmailForVerification()
{
// Arrange
var register = _sut.RegisterNotifications;
// Act
var result = _sut.Index(new RegisterUserViewModel(){ Password = "password",
Email = "john@smith.com", FirstName = "john", LastName = "smith“ })
as ViewResult;
// Assert
register.ReceivedWithAnyArgs().SendUserActivationActionEmail(null);
}](https://image.slidesharecdn.com/introtounittesting-121004084544-phpapp02/85/An-Introduction-to-unit-testing-9-320.jpg)
An Introduction to unit testing
- 1. Intro to unit testing Steven Casey twitter.com/stevencasey
- 2. An intro to a test of a unit Obligatory wikipedia quote: “unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine if they are fit for use” (emphasis mine) http://en.wikipedia.org/wiki/Unit_testing
- 3. What to test everything? nothing? what I feel like? Its a tough decision to decide where to draw the line between the obvious safety net of unit tests and the cost of writing & maintaining those unit tests.
- 4. • Lots of tests, will cost more to maintain over time and always have the potential to create almost as many problems as they solve. • BUT… • A lack of tests, doesn’t give you confidence to work with the glorious safety net that really good test coverage provides. • and, more importantly, quality assurance & rapid feedback
- 5. Tightrope? • Absolutely. One that requires discipline. Tests should be first-class code citizens. • Otherwise they can become useless, ignored, a dead pool of code that no-one wants to maintain. Then you have a new kind of legacy codebase… sad face
- 6. So, what to test? Use the force? Guess? Or, you can rely on a mix of complexity analysis (get yer cyclomatic complexity analysis ON), branches & iterations are candidates here Maybe, also considering edge-cases/boundary conditions for core business functions (xunit/mbunit for iterative testing rocks!) Or, if you have a legacy codebase. What are the hot classes always changing? Wouldn’t it be nice if you could wrap those in tests and optimize that code with confidence!
- 7. What not to test? What doesn’t add value? - Code that never changes (or least likely to…) AND isn’t broken (yet) - Code that cannot be mocked/faked. EG calling an API. - Non-public code! Only test the public interface of your class under test, not the internal implementation.
- 8. What not to test • Globals, statics, persistent data (DB, IO), distributed data (memcache) • You will quickly find yourself thinking, how can I test this and (hopefully) deciding to avoid globals & statics as much as possible. • Does your test connect to a shared db? Ok, stop! You cannot guarantee a repeatable isolated test there can you? Stay tuned for details on mocks/fakes/stubs!
- 9. How to structure a test? Arrange Act Assert: a sample… [TestMethod] public void RegisterWithValidInputs_SendsEmailForVerification() { // Arrange var register = _sut.RegisterNotifications; // Act var result = _sut.Index(new RegisterUserViewModel(){ Password = "password", Email = "john@smith.com", FirstName = "john", LastName = "smith“ }) as ViewResult; // Assert register.ReceivedWithAnyArgs().SendUserActivationActionEmail(null); }
- 10. RR Record-Replay • Record-Replay: for me, mind bending. I much prefer AAA and just about every OSS project I see does too. So, I will not cover it here. • For more, read: http://ayende.com/wiki/Rhino+Mocks+Record -playback+Syntax.ashx
- 11. Test structure, syntax • Follow a naming convention for tests. • A Suggestion is that you first name the method you are testing, the inputs, and the expected result. Be descriptive over shorthand, these descriptions will help identify quickly what test is failing when you have several hundred (or thousand) tests. • Alternative conventions exist: – GivenWhenThen syntax (my favourite approach for BDD-style tests)
- 12. Test Setup Avoid IOC. Testing your code is easier without registration logic. Use a mocking framework only for non-trivial dependencies. I recommend Nsubstitute! The testing framework usually has 2 types. One for class level and one method level which runs before/after every test. Use the method setup and teardown methods for creating and destroying the system(class) under test, to ensure a clean SUT for each test & keep the repetitive code out of your tests.
- 13. Some tips on writing tests… • Change code first, then tests. If u change both at once, well, how do u know which is broken! • Test’s should be independent of one another • Test one thing (behaviour) per test. (yes, its ok to have multiple asserts, as long as they all test the same behaviour) • No conditional logic, no loops, no exception catching (unless its an expected exception) • No test logic in production code
- 14. more tips… • Don’t create methods/props in production code only for use by tests (can you smell the bad design?) • 1 test class = 1 class under test (don’t mix the classes you are testing, it gets confusing quickly!)
- 15. Mocks, fakes, stubs, huh? • Stub: replaces implementation with code that returns a specific result. No asserts on stub. • Mock: all about asserting that something has been called, perhaps with particular params • Fake: anything that is not a ‘real’ implementation. You may create a fake to validate behaviours of SUT or to return specific results. • http://www.martinfowler.com/articles/mocksArentStubs.ht ml
- 16. A test of sorts… So finally, all your tests pass, w00t! But, someone finds a bug. What should your next steps be? If you said/thought… write a test to repro the bug and then fix the test. Well sir (or madam) , I think you got it!
- 17. Fin Initially written & presented 2010 @ communityengine. later adapted & posted for posterity here to have a nice reference for hopefully encouraging others to improve their approach to testing. Steven Casey. twitter.com/stevencasey. feedback encouraged! References: • http://blog.stevensanderson.com/2009/08/24/writing-great-unit- tests-best-and-worst-practises/ • http://www.slideshare.net/nickokiss/unit-testing-best-practices • Art of Unit Testing by Roy Osherove (read it!)