Unit tests & TDD

1,248
-1

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,248
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

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
  • Unit tests & TDD

    1. 1. Unit testing Dror Helper Senior consultant Tuesday, Novemeber 19, 2013
    2. 2. “Traditional” development Requirements Design Implementation Verification Maintenance
    3. 3. Integration surprises
    4. 4. Bugs are discovered too late
    5. 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. 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. 7. After writing a unit test Immune to regression Change your code without fear Enable Rapid changes In code documentation
    8. 8. What is a unit test? Test specific functionality Clear pass/fail criteria Good unit test runs in isolation
    9. 9. This is a unit test [TestMethod] public void CheckPassword_ValidUser_ReturnTrue() { bool result = CheckPassword(“user”, “pass”); Assert.IsTrue(result); }
    10. 10. This is also a unit test [Test] public void CheckPassword_ValidUser_ReturnTrue() { bool result = CheckPassword(“user”, “pass”); Assert.That(result, Is.True); }
    11. 11. Unit tests are written by developers
    12. 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. 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. 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. 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. 16. The test pyramid Manual testing UI automation Integration tests Unit tests
    17. 17. The test pyramid Manual testing UI automation End to End flow tests Scenario tests Integration tests Unit tests
    18. 18. Unit testing tools
    19. 19. Tools of the trade Server Build Server Source Control Build Script Dev Machine Unit Testing Framework Code Coverage Test Runner Isolation Framework
    20. 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. 21. Team Foundation Server (TFS)
    22. 22. TeamCity
    23. 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. 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. 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. 26. Attributes Declare information about the test: • TestClass/TestFixture • TestMethod/Test • ExpectedException • Ignore • And more
    27. 27. Test Runners Visual Studio  TestDrive.Net  R# TestRunner  CodeRush TestRunner 
    28. 28. Code coverage
    29. 29. Test Driven Development a software development process that relies on the repetition of a very short development cycle
    30. 30. Test Driven Development Red Refactor Green
    31. 31. The complete flow Write new Test Run all tests Run Test (fail) Refactor Write code Run test (pass)
    32. 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. 33. Examples, demonstrations & fun A DAY IN THE LIFE OF A TDD'ER
    34. 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. 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. 36. Writing Some Code  We begin with a clean slate Write new test Run tests Refactor Run All tests Write code
    37. 37. Writing Some Code  An exercise in futility… Write new test Run tests Refactor Run all tests Write code
    38. 38. Writing Some Code  Now we get our hands dirty Write new Test Run tests Refactor Run all tests Write code
    39. 39. Writing Some Code  Make sure everything’s fine… Write new Test Run tests Refactor Run all tests Write code
    40. 40. Writing Some Code  … and make it perform/look better Write new test Run tests Refactor Run all tests Write code
    41. 41. Writing Some Code  Lets take her out for another spin… Write new Test Run tests Refactor Run all tests Write code
    42. 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. 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. 44. Too Much Spare Time The foosball table The build bunny The Shooting of The Zombies Helping children with computer skills • • • •
    45. 45. The unit tester bookshelf
    46. 46. Presenter contact details C: 972.50.7668543 e: drorh@codevalue.net b: blog.drorhelper.com w: www.codevalue.net

    ×