Good Unit Tests Ask For Quality Code

  • 307 views
Uploaded on

The greatest benefit you will gain by writing good unit …

The greatest benefit you will gain by writing good unit
tests is the quality of your code design. Good unit tests put a high
pressure on refactoring your code to be testable, resulting
maintainable, extensible and reusable code. This will increase your
team efficiency. In this talk I will show what good unit tests mean,
how to write them and I will briefly exemplify how unit tests ask for
better code

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
307
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Good Unit Tests Ask For Quality Code Florin Coroş Software Architect, ISDC
  • 2. Code Design Qualities• Quality attributes for good code design: • Maintainability, • Extensibility, • Reusability• This is reached by: • OOD Principles, like SOLID principles, IoC, SoC… • Design Patterns: GoF • Experienced Developers• Main benefits: • Reduced cost of change • Reduced accidental complexity • Reduced cost of operation 2
  • 3. Good Unit Tests• Definition: • A unit test is an automated piece of code that invokes the method or class being tested and then checks some assumptions about the logical behavior of that method or class. • A unit test is almost always written using a unit-testing framework. • It can be written easily and runs quickly. • It’s fully automated, trustworthy, readable, and maintainable. • Quality Attributes of Good Unit Tests • Readable • Maintainable • Trustworthy 3
  • 4. Good Unit Tests - PropertiesA unit test should have the following properties:• It should be automated and repeatable.• It should be easy to implement.• Once it’s written, it should remain for future use.• Anyone should be able to run it.• It should run at the push of a button.• It should run quickly• It should run in isolation• It should test ONE thing• If it fails you should know exactly where the bug is 4
  • 5. Integration TestsDefinition• Integration testing means testing two or more dependent software modules as a group.Conclusion:• An integration test exercises many units of code that work together to evaluate one or more expected results from the software• An unit test exercises and tests only a single unit in isolation. 5
  • 6. External Dependencies, Stubs, Mocks• An external dependency is an object in your system that your code under test interacts with, and over which you have no control. (Common examples are file systems, threads, memory, time, and so on.)• A stub is a controllable replacement for an existing dependency (or collaborator) in the system. By using a stub, you can test your code without dealing with the dependency directly.• A mock object is a fake object in the system that decides whether the unit test has passed or failed. It does so by verifying whether the object under test interacted as expected with the fake object. There’s usually no more than one mock per test. 6
  • 7. Coding – Testing CycleCode First:1. Implement small chunk of functionality (a function)2. Write unit tests for it3. After all tests pass refactor the code, both production and test. Do itwith small changes and check that all the tests are still passing aftereach changeTests First (TDD)1. You may not write production code until you have written a failingunit test.2. You may not write more of a unit test than is sufficient to fail, and notcompiling is failing.3. You may not write more production code than is sufficient to pass thecurrent failing test.4. When all tests pass refactor the code. Do it with small changes andcheck that all the tests are still passing after each change. 7
  • 8. Practices To Remember• There is no object-oriented problem that cannot be solved by adding a layer of indirection, except, of course, too many layers of indirection.• Don’t treat your unit test code as second class citizen• Refactor by removing duplicates (DRY principle) 8
  • 9. Questions• e-mail: Florin.Coros@isdc.eu• twitter: @florincoros• blog: http://florincoros.wordpress.com 9