Agile Mëtteg series - Session 5

Editor's Notes

• #2: GFA
• #5: GFA
• #9: ERF/SZ
• #10: ERF
• #11: ERF
• #12: ERF
• #13: ERF
• #14: ERF
• #15: ERF
• #16: ERF
• #17: ERF
• #18: ERF(+SZ)
• #19: ERF
• #20: ERF
• #21: ERF
• #22: ERF
• #23: ERF
• #24: ERF
• #25: SZ
• #26: SZThe goal of unit testing is to isolate each part of the program and show that the individual parts are correct.Unit tests find problems early in the development cycle.A unit test provides a strict, written contract that the piece of code must satisfy. As a result, it affords several benefits.
• #27: SZ
• #28: SZMore confidence in the codeAvoid regression: If tests are run frequently the developer can see when new code breaks old code.The tests themselves are documentationEncourages better software design: simpler, smaller methods; less coupling instead of strongly coupled code[Compare introduction, maybe too similar?]
• #29: SZPrinciples for unit testsIt’s much easier to see:What is being set up and initialized in the arrange section What method is being executed in the act section What determines the outcome of the test in the assert section
• #30: SZ
• #31: SZOriginated in XP.Unit tests are essential parts of XP and other agile methods.
• #32: SZ
• #33: ERF
• #34: ERF
• #35: ERF
• #36: ERF
• #37: ERF
• #38: ERF
• #39: ERF
• #40: SZ
• #41: SZAcceptance tests are specifications for the desired behavior and functionality of a system. WHY?Although acceptance testing traditionally takes place at the end of development or major milestones, in agile software development acceptance testing needs to be performed at the user story level. There are several reasons for why this is important:A passed test case becomes a measure of completeness of a user story; that is, a user story cannot be considered complete till it has passed all acceptance tests associated with it. Even though there is thorough unit testing performed, this is not enough. Unit tests, by their nature, test for a localized used case and are not concerned about the overall system. When we have iterations longer than a couple of weeks, it becomes easy to loose focus on initial agreements; acceptance test cases made for each story at the beginning of each iteration help the developers to keep things within the expectations. Acceptance test cases can serve as an excellent guide to developers to better interpret the requirements from a user story
• #42: SZFit – the engineThe customers' examples are formatted in tables and saved as HTML using ordinary business tools such as Microsoft Excel. When Fit checks the document, it creates a copy and colors the tables green, red, and yellow according to whether the software behaved as expected. Fitnesse – Also the wiki on topFitNesse allows users of a developed system to enter specially formatted input (its format is accessible to non-programmers). This input is interpreted and tests are created automatically. These tests are then executed by the system and output is returned back to the user. The advantage of this approach is very fast feedback from users. The developer of the system to be tested needs to provide some support (classes named "fixtures", conforming to certain conventions). fast user feedbackERF demo -> score computation dino legs
• #43: ERF
• #44: SZI
• #45: SZBehavior-driven developmentBDD aims to help focus on the delivery of prioritised, verifiable business value by providing a common vocabularyBy using terminology focused on the behavioural aspects of the system rather than testing, BDD attempts to help direct developers towards a focus on the real value to be found in TDD at its most successful. "Behavior-driven development is what you are doing already, if you are doing Test-driven development well." (Dave Astels)Behavior Driven Development is more about interactions with the application than just unit testing. It forces the developer to understand the responsibility of the method he is about to write. Using good tools, the specs written to test the application can be used as specifications. Doing what comes naturallyBDD isn't anything new or revolutionary. It's just an evolutionary offshoot of TDD in which the word "test" is replaced by the word "should." Semantics aside, many people find the concept of should a much more natural development driver than the concept of testing. Thinking in terms of behavior (shoulds) somehow paves the way into writing specification classes first, which, in turn, can be a very efficient implementation driver.For many developers, the shift from test-driven development to BDD is a smart move. With BDD, you don't have to think about tests, you can just pay attention to the requirements of your application and ensure that the application behavior does what it should to meet those requirements. Using BDD to drive development Behavior driven development (BDD) is an evolutionary result of test driven development (TDD) in the sense that rather than thinking in terms of tests (which have the tendency to make you think after the fact) you can more easily think in terms of a specification. By thinking about an application’s specification or behavior, it becomes easier to validate things early– in fact, when thinking in terms of a specification, it becomes quite easy to write things upfront.
• #46: SZ
• #47: SZBDD relies on the use of a very specific (and small) vocabulary to minimize miscommunication and to ensure that everyone – the business, developers, testers, analysts and managers – are not only on the same page but using the same words. BDD provides a “ubiquitous language” for analysis Around this time, Eric Evans published his bestselling book Domain-Driven Design. In it, he describes the concept of modeling a system using a ubiquitous language based on the business domain, so that the business vocabulary permeates right into the codebase.
• #48: SZIStructural templatesFeature:As a [X]I want [Y]so that [Z] (In order)The template had to be loose enough that it wouldn’t feel artificial or constraining to analysts but structured enough that we could break the story into its constituent fragments and automate them. We started describing the acceptance criteria in terms of scenarios, which took the following form:Scenarios:Given some initial context (the givens),When an event occurs,then ensure some outcomes.
• #49: SZIStructural templatesFeature:As a [X]I want [Y]so that [Z] (In order)The template had to be loose enough that it wouldn’t feel artificial or constraining to analysts but structured enough that we could break the story into its constituent fragments and automate them. We started describing the acceptance criteria in terms of scenarios, which took the following form:Scenarios:Given some initial context (the givens),When an event occurs,then ensure some outcomes.
• #50: SZI
• #51: ERF
• #52: SZI
• #53: SZI