Scribd
Upload
74 views

C16 Effective Unit Testing

Effective Unit Testing with NUnit Unit testing involves writing small pieces of code to test specific functionality. The document outlines best practices for effective unit testing including automating tests, using good testing tools, writing tests first, designing code for testability, and maintaining tests. It also discusses common problems like poor test coverage, low quality tests, and code not designed for testing.

Uploaded by

Jai Singh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
74 views

C16 Effective Unit Testing

Effective Unit Testing with NUnit Unit testing involves writing small pieces of code to test specific functionality. The document outlines best practices for effective unit testing including automating tests, using good testing tools, writing tests first, designing code for testability, and maintaining tests. It also discusses common problems like poor test coverage, low quality tests, and code not designed for testing.

Uploaded by

Jai Singh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 46

Effective Unit Testing with NUnit

Win-Dev 2004
Friday, October 29, 2004

Peter Provost
Software Design Engineer
patterns & practices
Microsoft Corporation
Agenda
What is Unit Testing?
Typical Unit Testing Problems
Best Practices for Effective Unit Testing
Tools Demo
Q&A
What is Unit Testing?
A Definition
Unit Testing is code
that…
Is written by developers,
for developers.
Exercises a small,
specific area of
functionality.
Helps “prove” that a
piece of code does what
the developer expects it
to do.
What Unit Testing Is Not
Acceptance Testing (aka Functional Testing)
Performance Testing
Scalability Testing
Marick’s Four Quadrants of Testing
Business Facing

Support Development Customer Exploratory


Tests Tests

Critique Result
Scalability
Programmer Performance
Tests Usability
Security

Technology Facing

Source: Brian Marick – http://testing.com/


Why Unit Test
It will make your life
easier
Better code
Better designs
Code is easier to
maintain later
Confidence when you
code
Common Excuses
I’m not a tester!
It takes too much time.
It takes too long to run
the tests.
I don’t know how to
test it.
I don’t really know
what it is supposed to
do, so I can’t test it.
But it compiles! It
doesn’t need tests.
Typical Unit Testing Problems
Testing Is Monotonous and Boring
Often indicates bad tooling or bad techniques

Unit testing should…


Be easy to do
Provide rapid feedback
Poor Test Coverage
Often happens when tests not written first
Hard to retrofit later
Test coverage is orthogonal to test quality
Purpose of Tests is Misunderstood
Remember why we do unit testing
Easy to get distracted by irrelevant things
What is the scope of the test?
Informal Testing Process
How does your team do unit testing?

Test-first
Intuitive “poking and prodding” style testing
Smoke testing
Whatever the developer wants
Inconsistent Testing
Are tests required before check in?
How is it enforced?
Low Test Quality
Single biggest problem in unit testing today
Testing requires a special mindset
Tools only solve half the problem
Code Not Designed for Test
Often the cause of low test quality
Hard to design testable code
However, testable code often is better designed
Tests Not Maintained
So you’ve shipped your code and someone
finds a bug…
Do you fix the tests? Or just fix the bug?
What about the rest of the team?
Best Practices for Effective Unit
Testing
Automate Your Tests
If it is hard to run tests, you won’t do it
Manual (aka scripted) tests make regression
testing very hard
Use Good Tools
The tools should make it…
Easy to write tests
Easy to organize your tests
Easy to run tests (all, some, one)

They should provide…


Quick feedback of pass/fail
Details on the fail conditions
Use Good Tools
Testing Focused Tools Supporting Tools
NUnit NAnt
csUnit CodeRush
MbUnit Resharper
Test Driven .NET (aka CodeSmith
NUnitAddin)
NMock And of course…
DotNetMock Visual Studio .NET
Tools Demo
Get a Mentor
Testing is as much an art as a science
Learning to write good tests is hard
Some people are naturally good at it and some
aren’t
Use a Test List
Start your development activities by writing
down a list of things you want to test

You will often think of a test while writing


another one. When you do, add it to the list.

Review your list frequently


Write Tests First
Test-driven development (TDD) is a proven
way of improving quality*
TDD’s main objective is not testing software!
(this is a side effect)
TDD’s main objective is to aid programmers
and customers during the development process
with unambiguous requirements.
Code is written with testing as a primary
motivation. In short, the code is testable.
* - http://collaboration.csc.ncsu.edu/laurie/Papers/TDDpaperv8.pdf
What to Test
The “did we get what we expected” test isn’t
always good enough

Ask yourself the question…

“If the code ran correctly, how would I know?”


What to Test - Testing Heuristics
Test at the boundaries
Test every error message
Test different configurations
Run tests that are annoying to setup
Avoid redundant tests

Source: Lessons Learned in Software Testing, by Cem Kaner, James Bach, Brett
Pettichord
What to Test – BICEP
B Are the boundary conditions correct?

I Can you check inverse relationships?

C Can you cross check using other


means?
E Can you force an error condition to
happen?
P Are the performance characteristics
acceptable?

Source: Pragmatic Unit Testing in C# with NUnit by Andrew Hunt and


Dave Thomas
Test Structure
William Wake’s 3-A Pattern
Arrange
Act
Assert
Designing for Test
One simple question to help you write good
code…

“How am I going to test this?”

If you don’t know the answer, then you


probably need to reconsider your design.
Stubs and Mocks
Stub Defined
“ A portion is a portion of code that is inserted at
runtime in place of real code, in order to isolate
calling code from the real implementation. The intent
is to replace a complex behavior with a simpler one
that allows independent testing of some portion of
real code.”

Mock Objects Defined


“A mock object is an object created to stand in for an
object that your code will be collaborating with. Your
code can call methods on the mock object, will
deliver results as set up by your tests.”
Source: JUnit in Action, by Vincent Massol
When are stubs appropriate?
Objects that are expensive to create to
manipulate
At the edges of a system, or around complex
clusters of objects
Course-grained testing, integration testing
Stub Downsides
A Complex system might require a complex
stub
Hard to write in a verifiable way
Difficult to maintain
When are mocks appropriate?
Real object has non-
deterministic behavior
Real object is difficult
to set up
Real object has
behavior that is difficult
to cause
Real object is slow

Source:http://c2.com/cgi/wiki?
MockObjects
Mock Downsides
Code complexity of being able to switch
between real and mock implementations
Maintaining the mock
Properties of Good Tests
Automatic Tests need to be run checked
automatically
Thorough Test everything that could
possibly break
Repeatable Tests should produce the same
results each time they are run
Independent A test should exercise only one
thing at a time
Professional Tests are code too! Write them
professionally.

Source: Pragmatic Unit Testing in C# with NUnit by Andrew Hunt and Dave
Thomas
Test Organization Options
Tests in the VS Project being tested
Best for experiments, spikes, etc.

Tests in a separate VS Project


Most commonly used arrangement
Tests are not part of distribution

Tests in a separate VS Solution


The usual reference issues, but possible
Recommended Test Organization
Tests in a separate project/assembly
Naming conventions

If you are testing the class:


Foo.Bar.Baz

Then you should name your tests


Foo.Bar.Tests.BazTests

Note the namespace and test class name!


When to Run Tests
When you write a new method…
…compile and run local unit tests
When you fix a bug…
…run the test that illustrates that bug.
Any successful compile…
…run local unit tests.
Before you check in…
…run all tests.
Continuously…
...check out and build the project from scratch
including all unit tests.
Do not check in code that…
Is incomplete (e.g.
missing dependencies)
Doesn’t compile
Compiles but breaks
other code
Doesn’t have unit tests
Has failing unit tests
Passes its tests but
causes other tests to
fail.
Additional Resources
Web Sites
http://www.testdriven.com
http://www.xprogramming.com
http://workspaces.gotdotnet.com/tdd
Weblogs
Peter Provost
http://www.peterprovost.org
Jim Newkirk
http://weblogs.asp.net/jamesnewkirk
Brian Button
http://dotnetjunkies.com/WebLog/oneagilecoder/
Martin Fowler
http://www.martinfowler.com/bliki/
Darrell Norton
http://dotnetjunkies.com/WebLog/darrell.norton/
Mailing Lists
Yahoo Group: testdrivendevelopment
Yahoo Group: agiledotnet
Yahoo Group: extremeprogramming
Books
Test-Driven Development in Microsoft .NET –
James Newkirk and Alexei Vorontsov
Pragmatic Unit Testing in C# with NUnit –
Andrew Hunt and David Thomas
Test-Driven Development, by Example – Kent
Beck
Refactoring to Patterns – Joshua Kerievsky
Lessons Learned in Software Testing – Cem
Kaner, James Bach, and Brett Pettichord
Questions? Comments
Peter Provost
Software Design Engineer
patterns & practices
Microsoft Corporation

E-mail: peterpr@microsoft.com
Weblog: http://www.peterprovost.org/

NOTE: Updated slides available at


http://www.peterprovost.org/Files/C16_Effecti
ve_Unit_Testing.ppt

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy