Unit testing basics
•Download as PPTX, PDF•
0 likes•386 views
A presentation about unit tests benefits and implementation details.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Unit testing basics
Similar to Unit testing basics (20)
More from João Paulo Leonidas Fernandes Dias da Silva
More from João Paulo Leonidas Fernandes Dias da Silva (7)
Recently uploaded
Recently uploaded (20)
Unit testing basics
- 1. Unit Testing Overview and Best Practices
- 2. What’s unit testing? • Software development process. • Tests smallest parts of an application. • Individually and independently. • Always automated.
- 3. Why unit testing? • Quality • Test automation • Bug catching
- 4. Why unit testing? cont. • Documentation • Design Improving • Safe Refactoring • Avoid fear of changes
- 5. What’s an unit test? • Automated piece of code. • Checks assumptions (state and/or behaviour). • Unit of work. • Single end result.
- 6. What’s an unit of work? • Single logical functional use case. • Public interface. • A single method, a whole class or multiple classes.
- 7. Other levels of testing • Integration test • System/E2E test
- 8. A good unit test is: • Fully automated • Independent • Isolated • Deterministic
- 9. A good unit test is also: • Fast • Unitary • Readable • Maintainable • Trustworthy
- 10. Unit Testing Frameworks • xUnit • SUnit
- 11. xUnit Architecture • Test Runner • Test Case • Test Fixtures
- 12. xUnit Architecture cont. • Test Suites • Assertions • Test Result Formatter
- 13. A (N)unit test structure [TestFixture] public class SimpleTest { [Test] public void ShouldDoSomething() { //Given //When //Then } }
- 14. A simple class (SUT) public class Calculator { private double amount; public Calculator () { amount = 0; } public void SetAmount(double value) { amount = value; } public double GetAmount() { return amount; } public Calculator Add(double value) { amount += value; return this; } }
- 15. A simple (N)unit test [TestFixture] public class CalculatorTest { [Test] public void ShouldAddAPositiveAmount() { //Given Calculator calculator = new Calculator(); var initialAmount = 10; var amountToAdd = 30; var expectedAmount = 40; calculator.SetAmount(initialAmount); //When calculator.Add(amountToAdd); //Then Assert.AreEqual(expectedAmount, calculator.GetAmount()); } }
- 16. A class with a dependency public class Calculator { private double amount; private MathProcessor mathProcessor; public Calculator (MathProcessor mathProcessor) { amount = 0; self.mathProcessor = mathProcessor; } public void SetAmount(double value) { amount = value; } public double GetAmount() { return amount; } public Calculator Add(double value) { if (value > 1000000) { amount = mathProcessor.Add(amount, value); } else { amount += value; } return this; } }
- 17. A test using mock [TestFixture] public class CalculatorTest { [Test] public void ShouldUseMathProcessorForLargeNumbers() { //Given var initialAmount = 10; var amountToAdd = 3000000; var expectedAmount = 3000010; var mathProcessorMock = new Mock<MathProcessor>(); mathProcessorMock.Setup(m=>m.Add()). Returns(expectedAmount); Calculator calculator = new Calculator(mathProcessor.Object); calculator.SetAmount(initialAmount); //When calculator.Add(amountToAdd); //Then mathProcessorMock.Verify(m=>m.Add(initialAmount, amountToAdd)); } }
- 18. Test Doubles • Satisfy SUT dependencies when the actual implementation can not be used.
- 19. Test Doubles • The most common test doubles are the following: • Dummies • Fakes • Stubs • Spies • Mocks
- 20. Mocks vs. Stubs • You DO NOT assert against stubs. • You MUST assert against mocks.
- 21. State verification • Assert against the object state to make sure its state is correct.
- 22. Behaviour verification • Assert against mock(s) to check if the expectations were met. • Make sure the SUT is calling its dependencies correctly.
- 23. State vs Behaviour • When to test state? • When to test behaviour?
- 24. State vs Behaviour cont. • Excessive use of mocking can lead to the following issues: • Tests can be harder to understand. • Tests can be harder to maintain. • Tests can become less trustworthy. • Tests can become tautological.
- 25. Unit Tests Myths • It’s a waste of time • It makes changes more difficult to make • It slows down the development process • But it’s such simple code, why write a test? • Unit testing increases development costs
- 26. Making your code testable • Avoid using singletons and/or static classes and methods. • If it’s not possible, try using DI. • Avoid too many dependencies (more than 3).
- 27. Questions?
- 28. Thank you!
- 29. References • The Art of Unit Testing, 2nd Edition, Osherove, Roy • xUnit Test Patterns, Meszaros, Gerard • http://googletesting.blogspot.com.br/search/label/Tot T • http://artofunittesting.com/
Editor's Notes
- Unit testing is a software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinised for proper operation. Unit testing is always automated.
- 1) To focus on quality from the start - it’s impossible for a QA to ad-hoc test the whole system. The best person to test a functionality is the one who developed it. 2) To automate tests - unit tests should always be automated. Automation prevents human errors like forgetting to test a functionality. 3) To catch bugs earlier in the development process - the later in the development process you find a bug, the more expensive it will be to fix it.
- 1) To document your code - an example in code is better than lots of lines of text documentation. 2) To improve design (if using TDD) - writing tests first makes your design evolve as needed. You implement a small functionality, makes sure it works and then evolves it. Following this process iteratively often leads to a more simple and elegant design than trying to do everything up front. 3) To allow safe refactoring - refactoring without unit tests is dangerous and error prone. 4) To reduce fear - unit tests encourage us to make changes without the fear of breaking anything.
- A unit test is an automated piece of code that invokes the unit of work being tested, and then checks some assumptions about a single end result of that unit.
- A unit of work is a single logical functional use case in the system that can be invoked by some public interface. A unit of work can span a single method, a whole class or multiple classes working together to achieve one single logical purpose that can be verified.
- 1) Integration tests are tests that verify the interface between system components or modules, like external services, databases and file systems. 2) End to end tests are tests that traverse all the system layers (e.g. from the UI down to the database). Both types of tests can be automated.
- Needs to be able to be fully automated. There’s should be no need for any external intervention in order to run the test. 2) It can be run in any order if part of many other tests. There should be no dependencies between tests. 3) It has full control over all the pieces running. Doubles may be used to achieve this isolation when needed. A unit test runs in memory. There’s no DB or File access, for example. 4) Consistently returns the same result (deterministic). You always run the same test, so no random numbers, for example. Save those for integration tests.
- 1) Runs fast. 2) Tests a single logical concept in the system. 3) Readable. 4) Maintainable. 5) Trustworthy. When you see its result, you don’t need to debug the code just to be sure.
- xUnit - is the collective name for several unit testing frameworks that derive their structure and functionality from Smalltalk's SUnit. SUnit, designed by Kent Beck in 1998. It was written in a highly-structured object-oriented style, which lent easily to contemporary languages such as Java (JUnit) and C# (NUnit).
- Test Runner - Is an executable program that runs tests implemented using an xUnit framework and reports the test results. Test Case - Is the most elemental class. All unit tests are inherited from here. Test Fixtures - A test fixture (also known as a test context) is the set of preconditions or state needed to run a test. The developer should set up a known good state before the tests, and return to the original state after the tests.
- Test Suites - A test suite is a set of tests that all share the same fixture. The order of the tests shouldn't matter. Assertions - An assertion is a function or macro that verifies the state (or behaviour) of the unit under test. Usually an assertion expresses a logical condition that is true for results expected in a correctly running system under test (SUT). Failure of an assertion typically throws an exception, aborting the execution of the current test. Test Result Formatter - A test runner produces results in one or more output formats. In addition to a plain, human-readable format, there is often a test result formatter that produces XML output.
- Whenever the SUT has a dependency and it’s not possible (or desirable) to use the actual implementation, we use test doubles to satisfy this dependency so our tests can run properly.
- 1) Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists. 2) Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an InMemoryTestDatabase is a good example). 3) Stubs are objects that provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. We use stubs when we want to isolate our SUT from its dependencies. 4) Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent. 5) Mocks are objects that are pre-programmed with expectations which form a specification of the calls they are expected to receive. We use mocks when we want to test the behaviour of our SUT. We do that by verifying if the expected methods of the mock were called or not.
- A mock framework (Moq, RhinoMocks, etc.) can create both mocks and stubs. The differences between mocks and stubs are the following: You DO NOT assert against stubs. They are used only to replace the actual dependency implementation in order to isolate the SUT from its dependencies. You DO/MUST assert against mocks. Most mocks frameworks provide a method called verify which is used to check whether the expectations that were set on the mock object were met, i.e, the methods were actually called. We can say that mocks are stubs that are used in assertions. A mock can make a test fail, a stub can’t.
- It’s when, after you call the method under test, you assert against the object state to check if this method left the object in the expected state. In this case we want to make sure the method under test sets the object state correctly.
- It’s when, after you call the method under test, you assert against the mock(s) to check if the expectations were met, i.e, the expected methods on the mock(s) were called. In this case we want to make sure the method under test is calling its dependencies methods correctly. (Right order, right parameters, etc.)
- When to test state? Whenever it’s possible, i.e, when the method under test changes the state of the object being tested or returns a result (not void). When to test behaviour? 1) When the method under test has no side effect on the object being tested and/or does not return a result. Example: a Save method which does not change the state of the object being saved but calls a Logger class to log success or failure of the Save method. 2) When testing the return result and/or state of the object under test is not enough to guarantee correctness. Example: A Save method that returns the saved object also needs to decide if it should log to the file system or send an email, depending on a given business rule, although its result will always be the same (The saved object). 3) When the number and order of the calls to dependencies methods matter. If you need to guarantee that a call to the Save method will send only one email or log only one entry to the file system.
- Sometimes, testing only the behaviour does not guarantee that the returned result will be correct. You may end up just checking if the dependencies are being called correctly and not if they are doing the right thing. Excessive use of mocking can lead to the following issues: 1) Tests can be harder to understand - all that mock set up can distract you from the actual purpose of the test. 2) Tests can be harder to maintain - When you set up a mock you’re leaking implementation details into your test. If you change the implementation you also need to change your tests. Tests should know little or nothing about the implementation and focus only in the public interface of the SUT. 3) Tests can become less trustworthy - When you tell a mock how to behave, the only assurance you get with your tests is that your code will work if your mocks behave exactly like your real implementations. This can be very hard to guarantee, and the problem gets worse as your code changes over time, as the behaviour of the real implementations is likely to get out of sync with your mocks. 4) Tests can become tautological, i.e, redundant. A tautological tests it’s just a copy of the implementation.
- 1) What’s a waste of time? · Fixing the same bugs over and over · Writing and rewriting proofs throughout the development process · Fixing one bug, only to have another one magically appearing somewhere else · Getting interrupted in the middle of coding and completely losing your way. Resistance to unit testing is understandable, but many developers come around to understand its benefits once they complete a project with unit testing. 2) Not only is this false, it’s in fact the opposite. One of the biggest benefits of doing unit testing is the ability to implement large changes and immediately check that your changes have been done properly. Making changes and then later realizing that it’s affected other parts of your software, and then trying to isolate what caused the issue, is what not only makes changes difficult to make, it also causes developers to be wary of making changes. 3) Running unit tests might initially make the process seem slower, but the reality is that it saves time by preventing mistakes and recognizing them before the process goes too far. It also allows developers to have more confidence in the work they’ve already completed, thus clearing the way for progress. And throughout the life of the development process, the advantages of using unit testing can result in spending less time. 4) It seems simple, until something goes wrong. And then things aren’t so simple any more. Writing a unit test, even for simple code, adds stability and security to a project. 5) By decreasing the difficulty of implementing large changes, developers can be more flexible to the needs of the product itself, thus increasing chances for financial success.
- Static classes and methods are harder to mock/stub. 2) Dependency injection. Inject the object returned by the singleton or static method into your SUT. 3) If your SUT has too many dependencies your test may become harder to implement and understand.