Software development four variables
Cost Time Quality Scope
What can we control?
The most basic goal
Stunning, stable - various unpredictable mistakes on the beach, a little change
Easy to modify and expand - life is like a group of numbers involved in the content, and the price of unresceptive modifications exceeds endure
Basic Method & Principles Simple and minimal coupling, minimal dependency deductive package abstraction to modify closed, open and easy to test
Ancestral secret recipe
Discovering Better Code Unit Test Refactoring Principles & Practice
Unit test
Why: UNIT TEST Confirm that you do if you do understand what you want to do is the true positioning bug that you want to reduce, reducing the design of easy testing code before the Collateral Damage code can be executed.
Excuses For Not Testing It takes too much time to write the tests It takes too long to run the tests It's not my job to test my code I'm being paid to write code, not to write tests I feel guilty about putting testers and QA Staff Out of Work
What to Test: The Right-BICEP Right: Are the results right B: Are all the boundary conditions CORRECT I: Can you check inverse relationships C: Can you cross-check results using other means E: Can you force error conditions to happen P : Are Performance Characteristics Withnin Bounds
Are The Results Right's most basic test form
How to determine the result is correct
Give results in the most simple form Pass or no
Boundary Conditions has half mistakes from boundary needs special to strengthen the test of Boundary to find Boundary
Boundary: CORRECT Conformance: Does the value conform to an expected format Ordering:? Is the set of values ordered or unordered as appropriate Range:? Is the value within reasonable minimum and maximum values Reference:? Does the code reference anything external that isn ' t under direct control of the code itself Existence:? Does the value exist (non-null, nonzero, etc.) Cardinality:? Are there exactly enough values Time:? (absolute and relative): Is everything happening in order At the? Right Time? in time?
Check Inverse RelationShipS with reverse logic to verify results
To avoid interference, use different algorithms cross-check using other means to check with other algorithms
Use simple, stable algorithms to test advanced algorithms
Force Error Conditions error occurred, the code is not able to properly handle the foreseeable error: It is foreseeable to be an exception unpredictable or does not require special processing error parameters, front condition, environment, hardware, configuration, etc.
Performance Characteristics Do not consider performance with performance measurements
Test basic principles test as soon as possible, continuous testing automation does not change the state of the system without changing the system
Never run test code in officially running system
The basic principle of TEST is simple, effective and clear: Direct output tests need to pass the code to the biggest risk requires all the tests, not just the latest one
Test Related Tips Test Framework Input Output File Mock Object
Mock Object
Mock Object and the object to be tested with the same interface
Usage of Mock Object
Problems Test An Abstract Class Test Private Method Multi-Threaded Environment Test Gui
Database Test Enterprise Services Setup & Teardown Script Transaction Mock The DB Layer DBUnit Dependency DAL is implementation
Our tool introduction NUnit NUnitasp
Nunit.Framework.TestAttribute NUnit.Framework.Assert Nunit.Framework.ExpectedExceptionAttribute NUnit.Framework.IgnoreAttribute Nunit.Framework.SetUpAttribute Nunit.Framework.TearDownAttribute
Where to put test code The same file The same name Namespace parallel Namespace Separate Project
The habits we need to do have a CHECK LIST to move forward.
Some resources "preventing bugs with unit testing"
http://www.codertodeeveloper.com/4327c05.pdf
"Advanced Unit Testing"
http://www.codeproject.com/csharp/autp1.asp
MbUnit
http://mbunit.tigris.org
.NET MOCKOBJECTS
http://sourceforge.net/projects/dotnetmock
NUnit2Report
http://nunit2report.sourceforge.net/
NCOVER
http://ncover.sourceforge.net/
Nmock
http://nmock.truemesh.com/
NUNITADDIN
http://sourceforge.net/projects/nunitaddin
Further: Test drive development
Not the Unit Test Drive TDD is carried out around the specific function based on the requirements-driven TDD, rather than around a certain structure. Another document discusses separately
Reference "The pragmatic programmer" "refactoring: improving the design of existing code" "Pragmatic Unit Testing"
