Real Life Unit Testing


Published on

Tools are not enough. If you want to succeed overtime, you need more ammunition. Some people call them best practices. We call them real life lessons.Why should every developer unit test his code, Unit testing tools,TDD & Unit testing best practices, How to avoid writing fragile tests and Testing special scenarios

Published in: Technology, Education
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Software project should not be a ticking bomb.
  • AtomicRepeatableNo dependency between tests/test orderClear pass/fail criteria
  • The backbone of TDD (and development)Show how CI & script runner run the test suite – perhaps publish results to web
  • Real Life Unit Testing

    1. 1. Real life unit testing<br />Dror Helper<br />
    2. 2. Who am I?<br />Software Developer<br />Part time blogger<br />One thing was the same wherever I worked…<br />
    3. 3. Agenda<br />Unit tests - what, how and why<br />Tools of the trade<br />How to write better tests<br />Writing tests when it’s hard to test<br />
    4. 4. Sounds familiar?<br />Every ten bugs I fix I create a new one…<br />I have no idea what caused that issue…<br />I’d rather not change that function…<br />It is impossible to unit test our project!<br />Setting my test environment takes too long<br />
    5. 5. Avoid stupid bugs<br />
    6. 6. Unit tests<br />Unit Tests<br />Test specific functionality<br />Clear pass/fail criteria<br />Good unit test runs in isolation<br />
    7. 7. What is a Unit Test<br />Unit tests<br />[TestMethod]<br />public void CheckPassword_ValidUser_ReturnTrue()<br />{<br />bool result = CheckPassword(“user”, “pass”);<br />Assert.IsTrue(result);<br />}<br />
    8. 8. What is a Unit Test<br />Unit tests<br />[Test]<br />public void CheckPassword_ValidUser_ReturnTrue()<br />{<br />bool result = CheckPassword(“user”, “pass”);<br />Assert.That(result, Is.True);<br />}<br />
    9. 9. The kind of test<br />Unit tests should be:<br />Small<br />Atomic<br />Test a single functional unit<br />Isolated!<br />Integration tests are used to test system wide functionality<br />Unit tests<br />
    10. 10. Why use automated unit tests?<br />Quick feedback<br />Regression<br />Gain control of your code<br />Unit tests<br />
    11. 11. Avoid stupid bugs<br />Unit tests<br />
    12. 12. Tools of the trade<br />Tools<br />Server<br />Source Control<br />Build Server<br />Build Script<br />Dev Machine<br />Test Runner<br />Unit Testing Framework<br />Isolation Framework<br />Code Coverage<br />
    13. 13. Continuous Integration<br />Tools<br />What’s new?<br />Commit<br />Build Server<br />(TeamCity)<br />There you go<br />Start working<br />Build artifacts<br />We automatically got<br /><ul><li>Error reports & logs
    14. 14. New version installer
    15. 15. Help files
    16. 16. More…</li></ul>Source Control<br />(SVN)<br />Build Agents<br />(FinalBuilder)<br />
    17. 17. Build Script at a Glance<br />Tools<br />
    18. 18. TeamCity at a Glance<br />Tools<br />
    19. 19. Development environment<br />Make it easy to write and run tests<br />Unit test framework<br />Test Runner<br />Isolation framework<br />Know where you stand<br />Code coverage <br />Tools<br />
    20. 20. Unit testing frameworks<br />NUnit<br />xUnit<br />MSTest<br />Gallio (MbUnit)<br />NBehave<br />List of unit testing frameworks:<br />Tools<br />
    21. 21. Test Runners<br />Tools<br /><ul><li>Visual Studio (MSTest)
    22. 22. TestDrive.Net
    23. 23. R# TestRunner
    24. 24. CodeRushTestRunner
    25. 25. NUnitIt</li></li></ul><li>How to write better tests<br />Write better tests<br />Write easy to understand tests<br />Reuse code where appropriate<br />Running test should be easy<br />Avoid fragile tests<br />Trust Your Tests!<br />
    26. 26. Readability is important<br />Why did the test fail?<br />Avoid unnecessary debugging<br />Understand what the test does!<br />Write better tests<br />
    27. 27. Easy to understand unit tests<br />Names are important<br />Don’t be afraid to repeat yourself<br />Arrange-Act-Assert<br />Or Act-Assert-Arrange<br />Write better tests<br />
    28. 28. Write readable tests<br />Test only one thing (most of the time)<br />KISS – avoid logic in your test<br />Write better tests<br />
    29. 29. Duplicate code problem<br />Write better tests<br />After refactoring I need to re-write my tests.<br />Writing the same code twice is wrong<br />
    30. 30. Reuse code<br />Create objects using factories<br />Manipulate and configure initial state<br />Run common tests in common methods <br />Write better tests<br />
    31. 31. Just remember <br />Readability is important <br />- It’s still ok to repeat yourself<br />Write better tests<br />
    32. 32. Easy to run <br />Running the tests takes too long<br />Setting complicated testing environment<br />Write better tests<br />
    33. 33. Test should be easy to run<br />Integration vs. Unit tests<br />Simple configuration <br />Use fakes<br />Write better tests<br />
    34. 34. Fragile tests<br />Tests fail every time I change my code <br />Write better tests<br />
    35. 35. Avoid over specification<br />Write better tests<br />Don’t test private/internal (most of the time)<br />Fake as little as necessary<br />Test only one thing (most of the time)<br />
    36. 36. Testing the un-testable<br />First - better understand the problem<br />Isolation framework<br />Design/refactor for Testability<br />Reflection<br />Use integration tests<br />Testing un-testable<br />
    37. 37. Unit tests = avoid stupid bugs<br />
    38. 38. Resources<br />This Week In Test webcast<br />Book: The art of unit testing<br />Typemock insider’s blog:<br />Follow us on twitter @typemock<br />