Your SlideShare is downloading. ×
Unit tests & TDD
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Unit tests & TDD


Published on

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.

Published in: Technology

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • 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
  • 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:
    • 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)
    • 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: More TDD problems:
    • 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: b: w: