466 9754 [email protected] Are you here tonight? • Type something in the Chat window so I know you’re here. • This is one way for me to gauge your attendance and recognize your class participation. Image: http://blog.pluralsight.com/pluralsight-top-10-building-a-great-software-development-team
466 9754 [email protected] Experiments • Value: Individuals and interactions • Experiment #1: Use Adobe Connect breakout rooms again • Experiment #2: Everyone is a Presenter. If you get dropped from a breakout room, you should be able to move yourself back to your breakout room. • You are all presenters! Use the power wisely. • Value: Responding to change • Experiment #3: I am in a hotel room away from home. Network bandwidth is less than usual, but should be adequate for class.
466 9754 [email protected] Agile Requirements: Connection Responses: • Yash Patel: Definition of Done must be defined by team, Exit criterias must be clearly defined, tasks must be sized. • Frederick Jansen: Deliver working software frequently, customer satisfaction is the top priority, changing requirements are welcomed • Phillip Heller: subject to change • Jeff Pincus: you need a backlog • Evan Borysko: 1) Light weight artifacts 2) Written from user perspective 3) must be demostratable • Phillip Heller: Reasonably specific • philip: stake holders participate, • Justin Sanford: 1) Requirements define what the product increment that is to be built should do. 2) There are both functional requirements, and technical requirements. 3) Requirements aren't always perfect • Greg Gerrein 2: they must be clear, they must be testable, they must be doable • Matt Kubej: define the scope • Joey White: Generally user storiesUsually they have associated accteptance criteriaOften in the context of "as a user", but sometimes in other contexts • sbelov: 1) should come from the product owner2) defined just clearly enough to start work on the story • Phillip Heller: Developed in collab with customers / stakeholders. • Cyril (Tony) Allen: Product owner presents them.They are refined into backlog items in sprint planning.Stakeholders determine them. • philip: use inclusive models • Matt Kubej: can be used as testing criteria • Mark Warren: include a description of the value of the requirement
466 9754 [email protected] Agile Requirements: User Stories • What is a story we all know? • Title: Goldilocks and the Three Bears • Standard opening template: Once upon a time, there was a little girl and three bears. Goldilocks wanted to eat porridge because she was hungry. • One bowl was too hot, one bowl was too cold, and one bowl was just right. • The bears come home, notice someone was eating porridge, find Goldilocks asleep in little bear’s bed. • Acceptance criteria: Just then, Goldilocks woke up and saw the three bears. She screamed, "Help!" And she jumped up and ran out of the room. Goldilocks ran down the stairs, opened the door, and ran away into the forest. • The End Image: http://www.greenbookblog.org/2015/09/24/storytelling-new-science-is-enriching-an-ancient-art/, 2015-10-04
466 9754 [email protected] Agile Requirements: User Stories As a role-name , I want thing-I-want [so that value-I-receive ]. As a corporate user, I want to be able to subscribe and unscrible from company email list [so that …]
466 9754 [email protected] Agile Requirements: Acceptance Criteria • We’ll agree this story is completely implemented when: • testable predicate 1 • testable predicate 2 • … • Conditions of satisfaction for this user story • In addition to Definition of Done Image: http://elizabethholmes.com/travel-tools/pre-travel-checklist/, 2015-10-04
466 9754 [email protected] Agile Requirements: Concrete Practice • Write a user story for one of your real software requirements. • Who is your stakeholder? • What does she want? • Why? What value will she receive? • How will we agree we implemented it? As a _____________ I want _______________ so that _______________. Acceptance Criteria: - …
466 9754 [email protected] Behavior Driven Development: Connection • Remember TDD? • What is it? • What is the life cycle? • What tools have you used? • How is Acceptance Test Driven Development different from Unit Test Driven Development? Image: https://www.petfinder.com/helping-pets/careers-with-pets/careers-animal/, 2015-10-04
466 9754 [email protected] Behavior Driven Development: Connection Responses • Cornell Wright: Write the test first • Yetish Narayana: Develop test case to fail the product first • Usha: write test first and then the actual production code • Phillip Heller: Write the test, which will fail, then make the test pass. • Joey White: Write the tests first • Antonio Recalde Russo: test first, write later • Matt Kubej: Create unit test, write code until it passes • Mark Warren: write tests first • Jeff Pincus: Write a test that fails. Write just enough code to get it to pass. • Cornell Wright: then code • Yetish Narayana: then develop enough code to pass the test case • Joey White: Write the minimum code to make them pass • Rich Burgess: Write test for requirement first • Tomasz Skiba 2: acceptence test is aiming at user expirience • Shameek Nath: TDD - write tests first then implement code • David Collins 2: multiple flavors such as ping pong TDD • Linghong Chen: J unit, • Cornell Wright: you right the least amount of code possible to pass the test • PS (Nallasamy Ponnusamy): aceptance test could be focused on functionality rather than technical
466 9754 [email protected] BDD: What developers want • Why can’t the PO tell us what to build and why to build it, and give us enough detail to know what code to write? • Understand what your PO wants and give it to her • Know what code you are supposed to write before you start writing it • Your PO gives you great user stories with great acceptance criteria in Java because English is imprecise: @Test public void removeCarFromPoolWhenCustomerRentsCar() throws Throwable{ // Actual Java code goes here. I didn’t write any // because I’m a PO and I don’t write Java code! assertEquals(expectedNumOfCars, actualNumOfCars); } Image: http://www.zazzle.com/when_i_grow_up_i_want_to_be_a_software_developer_postcard-239996932325117830, 2015-10-04
466 9754 [email protected] BDD: What your PO wants • Why can’t the dev team build and deliver what our customers want? • Convey what to build to the dev team in English because I know English and I don’t write code. As a car rental company attendant, when a customer asks to rent a car, the computer tells me whether a car is available. And when the customer rents a car that is available, the computer removes that car from the pool of rentable cars.
466 9754 [email protected] BDD: How about something in between? • Express PBIs and acceptance criteria in an English-like domain-specific language • We all understand it • The PO can write it (collaborating with the dev team) • It is adequately precise • It is executable as an acceptance test! ====> TDD for acceptance tests =====> ATDD, BDD Feature: Rental cars should be possible to rent to gain revenue to the rental company. Story As an owner of a car rental company I want to make cars available for renting So I can make money Scenario: Find and rent a car Given there are 18 cars available for rental When I rent one Then there will only be 17 cars available for rental
466 9754 [email protected] BDD: What is it? • Behavior Driven Development is a form a Acceptance Test Driven Development (ATDD). • TDD at a higher level. Guides you as you code it the first time. Protects you as you refactor, add features, extend it. • Like all TDD: Finds bugs earlier and faster, when they’re less expensive to fix. • Work outside-in. Write a customer acceptance test first, watch it fail, write code until the tests pass, refactor, repeat. • Acceptance tests are written as concrete examples, not hypotheticals. Image: http://www.boost.co.nz/blog/2012/05/test-driven-development-and-agile/, 2015-10-04
466 9754 [email protected] BDD: Cucumber • Cucumber is a tool that reads your English-like feature definitions and executes them against your software under test. • Gerkhin is the syntax you use to specify the English-like feature definitions. • Features, scenarios, steps • Feature describes behavior of a feature of system • Contains a list of scenarios to test • Each scenario is a list of steps that are examples of how the system should work • Plain text • Filename ends in .feature • Lives in src/test/features directory • JUnit connector • Connects Cucumber to a JUnit test Runner • Java code • Filename ends in .java • Lives in src/test/java directory Excerpts From: Aslak Hellesøy. “The Cucumber Book”, iBooks. https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewBook?id=89E416A734EDBE781017A5AFD4775656
466 9754 [email protected] BDD: Cucumber • Step definitions • Converts the domain-specific English-like language into executable tests • Java code • Filename ends in .java • Does regex match of text from features file • Lives in src/test/java directory • Support code • Code and tools specific to your application • May include other automation tools, like Selenium • Application under test • Java code • Filename ends in .java • Lives in src/main/java directory Excerpts From: Aslak Hellesøy. “The Cucumber Book”, iBooks. https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewBook?id=89E416A734EDBE781017A5AFD4775656
466 9754 [email protected] BDD: Feature syntax • Gherkin • Trigger words: Given, When, Then, And, But • Given [initial context], when [event occurs], then [ensure some outcomes]. • Given some context, when some action is carried out, then a particular set of observable consequences should occur. • Martin Fowler’s explanation: The essential idea is to break down writing a scenario (or test) into three sections: • The given part describes the state of the world before you begin the behavior you're specifying in this scenario. You can think of it as the pre-conditions to the test. • The when section is that behavior that you're specifying. • Finally, the then section describes the changes you expect due to the specified behavior. Feature: User trades stocks Scenario: User requests a sell before close of trading Given I have 100 shares of MSFT stock And I have 150 shares of APPL stock And the time is before close of trading When I ask to sell 20 shares of MSFT stock Then I should have 80 shares of MSFT stock And I should have 150 shares of APPL stock And a sell order for 20 shares of MSFT stock should have been executed
466 9754 [email protected] BDD: Cucumber live example • Cucumber Tutorial rentit • Maven dependencies: junit, cucumber-java, cucumber-junit (and mvn install to download and install all the dependencies) • BDD • Write acceptance tests first: .feature file and first scenario • Run acceptance tests in Cucumber. Notice that they fail because glue code (step definitions) not implemented. Fix that. • Run acceptance tests. Notice that they fail. • Hand waving: Make believe we used Unit TDD until all unit tests go green … • Run acceptance tests. All green! • Add second scenario as a table of examples. • Run acceptance tests. Notice that one fails. • Talk to the PO. Agree that it’s a test error. Fix the test. • Run acceptance tests. All green! Image: http://www.boost.co.nz/blog/2012/05/test-driven-development-and-agile/, 2015-10-04
466 9754 [email protected] BDD: Concrete Practice • Practice: Cucumber for a small Java code sample • Install the Cucumber tools in your IDE. (Try Natural in Eclipse for editing Gherkin files. Or try the Cucumber Eclipse Plugin at site http://cucumber.github.com/cucumber-eclipse/update-site.) • Create a project, maybe using Maven. • Add Cucumber and JUnit to your project, maybe using Maven. • Write a .feature file. Run it. Notice that in JUnit, it looks like everything passed, but dig deeper. Notice the console output: it tells you what Step Definitions to write. • Add a RunCukesTest class. • Copy-paste the default step definitions. Run it. Notice that everything fails because the step definitions aren’t fully implemented. • Implement the step definitions. Run it. Notice that everything fails because the code isn’t written yet. • Implement the code until the tests pass.
466 9754 [email protected] BDD: Concrete Practice • Practice: Cucumber for a Java web service • Add Rest Assured to your project. (If you use Hamcrest, make sure it precedes JUnit in classpath.) • Write a .feature. • Add a RunCukesTest class. • Copy-paste the default step definitions. Run it. Notice that everything fails because the step definitions aren’t fully implemented. • Implement the step definitions using Rest Assured. Run it. Notice that everything fails because the code isn’t written yet. • Implement the code until the tests pass.
466 9754 [email protected] Homework • Practice BDD on your own • Install Cucumber tools in Eclipse. • Try some kata, e.g. any of Emily Bache’s kata https://github.com/emilybache • Use a Test First approach. Start with BDD tests in Cucumber. Continue with TDD unit tests in JUnit. Can you integrate Rest- assured or Selenium? • Search the web to read and learn about Agile long range planning and replanning, Open Space Technology, and Core Protocols. • Have fun! Image: http://www.livescience.com/51000-cucumber-nutrition.html, 2015-10-05
466 9754 [email protected] Were you here tonight? • Type something in the Chat window so I know you’re here. • This is one way for me to gauge your attendance and recognize your class participation. Image: http://blog.pluralsight.com/pluralsight-top-10-building-a-great-software-development-team
rkasper
signer
pokotyamu
matleenalaakso
japanstrokeassociation
yasulab
nagisa53
pnuslide
copilot
yuko_yokouchi
rocio
zakiwarfel
gr2m
philnash
kneath
iamctodd
panda_program
tammyeverts
destraynor
maggiecrowley
pauljervisheath
schacon
