• Save
Unit tests & TDD
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


Unit tests & TDD



A session I did at Rupin Academic Center.

A session I did at Rupin Academic Center.
Part of modern software engineering course for bachelor degree in computer science.



Total Views
Views on SlideShare
Embed Views



2 Embeds 4

http://www.linkedin.com 3
https://www.linkedin.com 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Example: writing unit tests
  • Ask them – why is the test name so important?
  • Succeeding with Agile. Cohn, Mike
  • Succeeding with Agile. Cohn, Mike
  • The backbone of TDD (and development)Show how CI & script runner run the test suite – perhaps publish results to web
  • Should show:NUnit
  • Resharper

Unit tests & TDD Presentation Transcript

  • 1. Unit testing Dror Helper Senior consultant Tuesday, Novemeber 19, 2013
  • 2. “Traditional” development Requirements Design Implementation Verification Maintenance
  • 3. Integration surprises
  • 4. Bugs are discovered too late
  • 5. The cost of bugs Where does it hurt? 100% The pain is here! This is too late… 9 8 7 60% 6 5 40% 4 3 20% 2 1 0% 0 Requirements Coding Integration % of Defects Introduced Testing Cost to Fix a Defect Support Thousand $s % defects created 80% 10
  • 6. When writing unit tests Quick feedback Am I writing the code right? Am I’m writing the right thing? Dependency & API analysis Avoid stupid bugs
  • 7. After writing a unit test Immune to regression Change your code without fear Enable Rapid changes In code documentation
  • 8. What is a unit test? Test specific functionality Clear pass/fail criteria Good unit test runs in isolation
  • 9. This is a unit test [TestMethod] public void CheckPassword_ValidUser_ReturnTrue() { bool result = CheckPassword(“user”, “pass”); Assert.IsTrue(result); }
  • 10. This is also a unit test [Test] public void CheckPassword_ValidUser_ReturnTrue() { bool result = CheckPassword(“user”, “pass”); Assert.That(result, Is.True); }
  • 11. Unit tests are written by developers
  • 12. Arrange Act Assert Divide the unit test into three parts: [Test] public void test() throws Exception { // Arrange int first = 1; int second = 2; Calculator calc = new Calculator(); // Act int result = calc.Add(first, Second); // Assert Assert.AreEquals(3, result); }
  • 13. Project structure It is crucial to have a consistent naming convention: For Project: <project under test>Tests or <project under test>.UnitTests <project under test>.IntegrationTests For files (Test case): <class under test>Tests Example: CalculatorTests Never have your test in the same project as your production code!
  • 14. Test naming Test names should be descriptive and explicit. Test names should express a specific requirement I like to use: Method_Scenario_Expected a.k.a UnitOfWork_StateUnderTest_ExpectedBehavior Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() Public void Sum_simpleValues_Calculated () Public void Parse_SingleToken_ReturnsEqualTokenValue () From: http://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html
  • 15. Test classification Unit tests should be: – Small – Atomic – Test a single functional unit – Isolated! Integration tests are used to test system wide functionality
  • 16. The test pyramid Manual testing UI automation Integration tests Unit tests
  • 17. The test pyramid Manual testing UI automation End to End flow tests Scenario tests Integration tests Unit tests
  • 18. Unit testing tools
  • 19. Tools of the trade Server Build Server Source Control Build Script Dev Machine Unit Testing Framework Code Coverage Test Runner Isolation Framework
  • 20. Continuous Integration Server Build What’s new? Commit There you go Source Control We automatically got •Error reports & logs •New version installer •Help files •More… Build Agents
  • 21. Team Foundation Server (TFS)
  • 22. TeamCity
  • 23. Development environment • Make it easy to write and run tests – Unit test framework – Test Runner – Isolation framework • Know where you stand – Code coverage
  • 24. Unit test framework Simplify the process of unit testing Provide the following: Control flow (attributes) Signal success/failure (Assertions) http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
  • 25. Assertions Throw exception when condition is false. Easy to find: Assert.X StringAssert.X CollectionAssert.X New Syntax (Nunit): Assert.That(x, Is.Equal(y));
  • 26. Attributes Declare information about the test: • TestClass/TestFixture • TestMethod/Test • ExpectedException • Ignore • And more
  • 27. Test Runners Visual Studio  TestDrive.Net  R# TestRunner  CodeRush TestRunner 
  • 28. Code coverage
  • 29. Test Driven Development a software development process that relies on the repetition of a very short development cycle
  • 30. Test Driven Development Red Refactor Green
  • 31. The complete flow Write new Test Run all tests Run Test (fail) Refactor Write code Run test (pass)
  • 32. Unit tests != TDD • The purpose of a unit test is to test a unit of code in isolation • TDD is used to drive the design of an application. • used to express what application code should do before the application code is actually written.
  • 33. Examples, demonstrations & fun A DAY IN THE LIFE OF A TDD'ER
  • 34. A Day in the Life of a TDD'er • The tools we use • Writing some code • OK, who broke the Build?! • Too much spare time…
  • 35. The Tools We Use(d) • • • • • • Unit testing – MSTest/NUnit Build automation – FinalBuilder Continuous Integration – TeamCity Integrated tools – R#, TestDriven.NET Isolation Framework – Isolator (surprise!) Build Bunny!
  • 36. Writing Some Code  We begin with a clean slate Write new test Run tests Refactor Run All tests Write code
  • 37. Writing Some Code  An exercise in futility… Write new test Run tests Refactor Run all tests Write code
  • 38. Writing Some Code  Now we get our hands dirty Write new Test Run tests Refactor Run all tests Write code
  • 39. Writing Some Code  Make sure everything’s fine… Write new Test Run tests Refactor Run all tests Write code
  • 40. Writing Some Code  … and make it perform/look better Write new test Run tests Refactor Run all tests Write code
  • 41. Writing Some Code  Lets take her out for another spin… Write new Test Run tests Refactor Run all tests Write code
  • 42. Want to learn more Check out the bowling kata: http://www.objectmentor.com/resources/articles/xpepisode.htm More TDD problems: https://sites.google.com/site/tddproblems/all-problems-1
  • 43. OK, Who Broke the Build? • Something went horribly wrong! – And it’s easy to find who to blame  – But it’s easy to find out what happened • Why is this important? – The project heartbeat – Healthy build == easy to release
  • 44. Too Much Spare Time The foosball table The build bunny The Shooting of The Zombies Helping children with computer skills • • • •
  • 45. The unit tester bookshelf
  • 46. Presenter contact details C: 972.50.7668543 e: drorh@codevalue.net b: blog.drorhelper.com w: www.codevalue.net