Test Driven Development (Delphi)


Published on

Published in: Technology, Education
1 Like
  • Be the first to comment

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

No notes for slide
  • Delphi simply uses Dunit, which is built into Xe2 (and indeed earlier versions).
  • This code in Delphi would read something like the new image pasted above.
  • The procedure here should simply be capitalized, as in the example above
  • Delphi uses ‘Assert’ function, which can be used happily in DUnit. Assert tests whether a boolean argument is True. Eg. Assert(expected = actual);DUnit also provides:Check() - Checks to see if a condition was met. CheckEquals() - Checks to see that two items are equal. CheckNotEquals() - Checks to see if items are not equal. CheckNotNull() - Checks to see that an item is not null. CheckNull() - Checks to see that an item is null. CheckSame() - Checks to see that two items have the same value. Fail() - Checks that a routine fails. FailEquals() - Checks to see that a failure equals a specified failure condition. FailNotEquals() - Checks to see that a failure condition does not equal a specified failure condition. FailNotSame() - Checks to see that two failure conditions are not the same. EqualsErrorMessage() - Checks to see that an error message emitted by the application matches a specified error message. NotEqualsErrorMessage() - Checks to see that two error messages are not the same. NotSameErrorMessage() - Checks that one error message does not match a specified error message.
  • In Delphi we would just ‘OutputDebugString()’, which sends the output to the Delphi EventLog window.
  • These are all relevant to Delphi. There are refactoring methods in Delphi that some of us use to a greater or lesser extent – perhaps link to here:http://docwiki.embarcadero.com/RADStudio/en/Refactoring_Applications_Index
  • Test Driven Development (Delphi)

    1. 1. First, Some History
    2. 2. Plan-Do-Check-Act0 Originally called Plan-Do-Study-Act0 Created by Walter Shewhart at Bell Labs during the 1930s
    3. 3. Iterative & Incremental Development0 The X-15 program in the 1950s used IID
    4. 4. Test-First in the Swinging 60s0 X-15 team members seeded Project Mercury 0 Time-boxed half-day iterations 0 Tests were written first 0 Reviews after each iteration 0 Top-down development with stubs
    5. 5. We were doing incremental development as early as 1957, in Los Angeles, underthe direction of Bernie Dimsdale [at IBM’s Service Bureau Corporation]. He wasa colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell, indistinguishable from XP. When much of the same team was reassembled in Washington, DC in 1958 todevelop Project Mercury, we had our own machine and the new Share Operating System, whose symbolic modification and assembly allowed us to build the system incrementally, which we did, with great success. Project Mercury was the seed bed out of which grew the IBM Federal SystemsDivision. Thus, that division started with a history and tradition of incremental development. All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities… I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for “software development.” Gerald M. Weinberg
    6. 6. Waterfall in the 1970s & 80s0 Blame the DoD and the CMMI
    7. 7. Other stuff was happening0 Object-orientation 0 Simula from the late 60s 0 Smalltalk in the 70s at Xerox PARC0 Software distribution
    8. 8. Into the 1990s0 UML evolves0 www arrives
    9. 9. What RUP was meant to be
    10. 10. What RUP actually was
    11. 11. RAD elaboration in the 90s
    12. 12. XP arrives
    13. 13. Test-Driven is in XP
    14. 14. Tests are Feedback in XP
    15. 15. Agile arrives
    16. 16. Agile is just XP, rebadged
    17. 17. and a Manifesto
    18. 18. The Philosophy of TDD
    19. 19. The Testing Game0 Red: 0 “Write a failing test”0 Green: 0 “Pass the failing test”0 Refactor 0 “Clean the implementation”
    20. 20. Write a failing test0 To know what test to write, you must: 0 Analyze your problem 0 Design your solution 0 Code intentionally0 To dislike “Big Upfront Design” is not to dislike design
    21. 21. Agile Problem Analysis0 System Metaphor 0 Arises from the Architectural Spike 0 A simple design with the defining quality of explaining the system design without reference to documents0 User Experience 0 Arises from the set of all user stories 0 Provides a canvas onto which individual stories can be painted0 User Story 0 Describes a specific user expectation 0 Provides the functional constraints of implementation
    22. 22. User Stories0 A user story comprises one or more sentences in the everyday or business language of the end user that captures what the user wants to achieve
    23. 23. Agile Solutions0 “Walk the solution”: for each user story 0 Understand how this fits into the user experience 0 Understand where the necessary functional implementation goes in the architecture 0 Design the functional implementation
    24. 24. Goldilocks Design0 Design only what you need 0 avoid YAGNI (You Ain’t Gonna Need It)0 Reuse existing implementation 0 be DRY (Don’t Repeat Yourself)0 Prefer sketched designs over definitive design 0 allow TDD to be part of your design process0 Don’t experiment in code 0 use spikes where necessary
    25. 25. First Exercise0 Brainstorm a realistic candidate application0 Write a small set of user stories0 Elaborate a user experience0 Articulate a system metaphor0 Time limit: one hour
    26. 26. Analysis & Design0 There are a variety of approaches to functional analysis and implementation design0 The most commonly used are: 0 The UML 0 CRC Cards 0 Design Patterns 0 Linguistics & Semantics 0 Personas 0 Storyboards
    27. 27. UML0 The UML (Unified Modeling Language) 0 It has the advantage that many developers have at least some familiarity 0 It has the disadvantage of significant complexity 0 Most agile practitioners use ‘sketch’ UML, typically on a whiteboard, in order to convey a mental model of a proposed solution 0 Be indicative, not definitive
    28. 28. UML Use Case Diagram0 Describes the functionality provided by a system in terms of actors and their goals represented as use cases
    29. 29. UML Activity Diagram0 Used to describe the business and operational step-by-step workflows of components in a system
    30. 30. UML Sequence Diagram0 Shows how processes operate with one another and in what sequence
    31. 31. UML Class Diagram0 Describes the structure of a system by showing the systems classes, their attributes, methods, and the relationships among the classes
    32. 32. CRC Cards0 Class Responsibility Collaboration cards are a brainstorming tool, proposed by Ward Cunningham and Kent Beck0 They are typically used when determining which classes are needed and how they will interact0 CRC cards are usually created from index cards on which are written: 0 The class name 0 Any base or derived classes (if applicable) 0 The responsibilities of the class 0 The names of other classes with which the class will collaborate to fulfil its responsibilities
    33. 33. CRC Card
    34. 34. Design Patterns0 A general reusable solution to a commonly occurring problem within a given context0 A design pattern is not a finished design that can be transformed directly into code; it is a description or template for how to solve a problem that can be used in many different situations0 Typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved
    35. 35. Some Creational Patterns0 Factory method 0 Define an interface for creating an object, but let derived classes decide which class to instantiate0 Lazy initialization 0 Tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed0 Object pool 0 Avoid expensive acquisition and release of resources by recycling objects that are no longer in use0 Resource acquisition is initialization 0 Ensure that resources are properly released by tying them to the lifespan of suitable objects0 Singleton 0 Ensure a class has only one instance, and provide a global point of access to it
    36. 36. Some Structural Patterns0 Adapter 0 Convert the interface of a class into another interface clients expect0 Bridge 0 Decouple an abstraction from its implementation allowing the two to vary independently0 Facade 0 Provide a unified interface to a set of interfaces in a subsystem0 Proxy 0 Provide a surrogate or placeholder for another object to control access to it
    37. 37. Some Behavioural Patterns0 Chain of responsibility 0 Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request0 Command 0 Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations0 Iterator 0 Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation0 Null object 0 Avoid null references by providing a default object
    38. 38. Linguistics & Semantics0 Using the meanings and relationships of words and phrases employed in the user stories and other material to construct a language map of the problem domain0 Especially useful when dealing with ‘expert’ systems
    39. 39. Personas0 Fictional characters created to represent the different user types within a targeted demographic, attitude and/or behaviour set that might use a site, brand or product in a similar way
    40. 40. Storyboards 0 A technique borrowed from the film industry 0 Shows the user experience in sequence
    41. 41. Second Exercise0 Take one or more of the user stories from the first exercise and apply a selection of the analysis and design techniques0 Draw up a list of the strengths and weaknesses of the techniques in relation to these particular user stories0 Time limit: one hour
    42. 42. Testing Frameworks0 MSTest 0 Built-in to Visual Studio0 Pex 0 Experimental white-box testing from MS Research0 NUnit 0 Early open source port of JUnit for .net0 MbUnit 0 Another open source framework0 xUnit 0 Open source reset of NUnit0 SpecFlow 0 Open source behaviour-driven-development framework
    43. 43. Arrange, Act, Assert0 The default pattern for unit tests 1. Arrange all necessary preconditions and inputs 2. Act on the object or method under test 3. Assert that the expected results have occurred
    44. 44. Test naming conventions0 Ad-hoc 0 Anything goes0 Behavioural 0 Tests are named according to the behaviour under test 0 Good fit for collaboration tests (distinct from unit tests) procedure CustomerPaysInChequeToCurrentAccount;0 Contractual 0 Names follow the unit contract under test http://alandean.blogspot.com/2011/11/unit-test-naming-convention.html
    45. 45. DUnit Assertions0 Fundamentals 0 Assert(…) 0 Check(…) 0 CheckSame(…) 0 CheckEquals(…) or CheckNotEquals(…) 0 CheckNull(…) or CheckNotNull(…) 0 Fail(…) 0 FailNotSame(…) 0 FailEquals(…) or FailNotEquals(…)0 Errors 0 NotSameErrorMessage(…) 0 EqualsErrorMessage(…) or NotEqualsErrorMessage(…)
    46. 46. Diagnostics0 OutputDebugString(…)
    47. 47. TDD at the Keyboard1. Add a new test2. Run all tests and see if the new one fails3. Write some code4. Run all tests and see them succeed5. Refactor code6. Repeat
    48. 48. Exercise 30 Create a solution with two class libraries: 0 TicTacToe 0 TicTacToe.Facts0 Add a reference to xUnit.net in the Facts library 0 http://nuget.org/0 Use TDD to implement Tic-Tac-Toe 0 http://gojko.net/2009/08/02/tdd-as-if-you-meant-it-revisited/0 Time limit: one hour
    49. 49. Refactoring Code0 A disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behaviour0 Usually motivated by noticing a code smell0 There are two general categories of benefits to the activity of refactoring 0 Maintainability 0 It is easier to fix bugs because the source code is easy to read and the intent of its author is easy to grasp 0 This might be achieved by reducing large monolithic routines into a set of individually concise, well-named, single-purpose methods 0 It might be achieved by moving a method to a more appropriate class, or by removing misleading comments. 0 Extensibility 0 It is easier to extend the capabilities of the application if it uses recognizable design patterns, and it provides some flexibility where none before may have existed
    50. 50. Refactoring Techniques0 Techniques that allow for more abstraction 0 Encapsulate Field: force code to access the field with getter and setter methods 0 Generalize Type: create more general types to allow for more code sharing 0 Replace Conditional with Polymorphism: move each leg of the conditional to an overriding method in a derived class and make the original method abstract0 Techniques for breaking code apart into more logical pieces 0 Extract Method: turn part of a larger method into a new method 0 Extract Class: moves part of the code from an existing class into a new class0 Techniques for improving names and location of code 0 Move Method or Field: move to a more appropriate class 0 Rename Method or Field: changing the name to one that better reveals its purpose 0 Pull Up: move to a base class 0 Push Down: move to a derived class0 Longer lists 0 http://martinfowler.com/refactoring/catalog/index.html 0 http://docwiki.embarcadero.com/RADStudio/en/Refactoring_Applications_Index
    51. 51. Exercise 40 Create a solution with two class libraries: 0 RomanNumerals 0 RomanNumerals.Facts0 Use TDD to solve the problem 0 https://sites.google.com/site/tddproblems/all-problems-1/Roman-number-conversion0 Refactor the code as you go0 Time limit: one hour
    52. 52. Test Doubles0 Objects that mimic real objects for testing purposes 0 Dummies 0 Have no behaviour or throw exceptions 0 Stubs 0 Provide the behaviour of a real object 0 Spies 0 Record activity for later verification 0 Mocks 0 Define the expected activity before the test is run 0 Fakes 0 Employ a simpler implementation such as an in-memory database0 See also http://martinfowler.com/articles/mocksArentStubs.html
    53. 53. Mocking Frameworks0 Visual Studio doesn’t have one built-in0 Moles 0 Experimental framework from MS Research0 Open source 0 Moq, NCrunch, NMock2, Rhino Mocks, fakeiteasy0 Commercial 0 TypeMock Isolator, JustMock
    54. 54. SOLID Code0 Single Responsibility principle 0 An object should have only a single responsibility0 Open/Closed principle 0 Objects should be open for extension, but closed for modification0 Liskov Substitution principle 0 Objects should be replaceable with instances of their derived types without altering correctness0 Interface Segregation principle 0 Many client specific interfaces are better than one general purpose interface0 Dependency Inversion principle 0 Depend upon abstractions; do not depend upon concretions
    55. 55. Inversion of Control0 Microsoft 0 Unity 0 Common Service Locator0 Open source 0 Castle Windsor, Autofac, StructureMap, Ninject, LinFu
    56. 56. Exercise 50 Create a solution with two class libraries: 0 Translator 0 Translator.Facts0 Use TDD to solve the problem 0 TODO0 Refactor the code as you go0 Use test doubles to isolate tests from dependencies and resources to achieve SOLID code0 Time limit: two hours
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.