Please enable JavaScript.
Coggle requires JavaScript to display documents.
The Art of Unit Testing, rate each component for these factors 1(low) -…
The Art of Unit Testing
The basics
Definition
- 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 the sum of actions that take place between the invocation of a public method in the system and a single noticeable end result by a test of that system.
A noticeable end result can be observed without looking at the internal state of the system and only through its public APIs and behavior
-
A noticeable change to the state or behavior of the system before and after invocation that can be determined without interrogating private state
-
- Integration testing is testing a unit of work without having full control over all of it and using one or more of its real dependencies, such as time, network, database and so on
- A regression is one or more units of work that once worked and now don't
- Control flow code is any piece of code that has some sort of logic in it. It has one or more of the following: if, loop, switch, calculations or any other type of decision-making code
- Refactoring means changing a piece of code without changing its functionality
-
-
-
Best Practices
-
-
Use Factory methods to reuse code in your tests, such as creating and initializing objects
Don't use setUp()
and tearDown
if you can avoid them, since they make tests less understandable
Unit Test Types
-
State Based
-
The method under test change the state of the system. So the state before and after the method invocation is evaluated
Interaction
-
It's an action-driven testing, which means that you test a particular action an object takes.
-
-
Mock vs Stubs
- A stub can never fail a test
- A mock is used to verify whether or not the test failed
Using stub
Using mock
- Creating and using a mock object is much like using a stub, except that a mock will do a little more than a stub: it will save the history of communication, which will later be verified in the form of expectations.
- In other words, if the fake object has a state which is used on assertions, this is called mock. On the other hand, if the fake object doesn't have a state and is just used to replace a direct dependency and simulate a particular case, then is called stub.
Only one mock object per test that is testing only one thing. All the other fake objects should be stubs
-
Running Tests
-
-
Steps
-
- Run all tests to make sure that you haven't broken any existing functionality
- make sure that your code can still integrate well and not break any other project you depend on
- create a deliverable package and deploy
Separate Unit from Integration tests, because the developers should run them as often as they need and should not be time consuming
-
-
-
-
-