software engineering 2 (swt2) - hasso plattner...

Software Engineering 2 (SWT2)

Chapter 5: Getting you ready for the project

- Lego Scrum Exercise, Git, Infrastructure, your next week, Testing, PO presentation -

Agenda

■  Lego Scrum Exercise

■  Git

■  Project Infrastructure

■  Application Stub ■  Your next week in a nutshell

■  Introduction into Testing in Rails

■  Outlook

■  PO Presentation

SWT2 | Chapter 5: Getting you ready for the project | WS2010/2011

2

Lego Scrum Exercise

■  Goal of the exercise

□  recap all Scrum meetings

□  Practice for next weeks

■  Background: {Hasso|Larry} bought an lonesome island

■  Your task: develop the island for tourism


3

Lego Scrum Exercise

■  Ingredients

□  A0 map

□  Lots of Lego

□  Post It’s ■  Timeboxed activities (3x)

□  Planning (5min)

□  Conduct sprint (10min)

□  Review (3min)

□  Retrospective (2min)

■  I like, I wish (in team) ■  I like, I wish (in group)


4

Lego Scrum Exercise

■  Planning

□  PO presents User Story (we prepared some)

□  Design session / Task break down

□  Estimation

□  Time left? Next Story

■  Conduct sprint


5

Lego Scrum Exercise

■  Review

□  Team presents User Story results

□  PO accepts/rejects ■  Retrospective

□  What can be improved?

□  Process adjustments?

□  How do you feel?

□  ...


6

Lego Scrum Exercise


7

Lego Scrum Exercise

■  POs are encouraged to

□  adjust User Stories

□  remove/add User Stories

□  refine User Stories

■  SMs

□  keep track of estimations

□  keep track of time

□  oversee Scrum process

□  moderate meetings


8

Lego Scrum Exercise

■  Group Hasso

□  Lego now!

□  5 teams (three are split up [G2, H2 & W2])

□  HS1 + Foyer

■  Group Larry

□  Lego at 1:30pm

□  5 teams (three are split up [D1, M1 & M2])

□  HS1 + Foyer


9

Agenda


■  Git




■  Outlook



10

Git


11

Agenda


■  Git




■  Outlook



12

Email

■  Mailing lists

□  [email protected]

□  swt2_2010_hasso, swt2_2010_hasso_{po|sm}

□  swt2_2010_larry, swt2_2010_larry_{po|sm} □  swt2_2010_{b1|d1|d2|g1|g2|h1|h2|m1|m2|

n1|n2|p1|w1|w2|hp1|hp2}

□  Keep your teammates in the loop

□  Rules / filters are your friend

■  Anonymous email address: [email protected]


13

Time Management


Google Calendar

■  Advantages:

□  Available Everywhere □  Easy Integration with Outlook & iCal

(see “Useful Links” in Wiki)

■  Overview of team appointments

■  Access granted by tutors

14

Continuous Integration


■  Problem: How to check continously that your software works?

■  Solution: Continuous Integration (CI) Server   Connected to version control   Customizable run scripts   Ideally covering all development branches   Checkout prepare environment run tests run statistics   Examples: CruiseControl, Anthill   Our system: Hudson (http://hudson-ci.org/)   http://ares.epic.hpi.uni-potsdam.de/swt2-ci/

  Deployment to:   Hasso: http://192.168.30.90:10080   Larry: http://192.168.30.90:11080

15

Application Lifecycle Management


■  Integrating tools for most common activities in one place

■  Wiki, Bug Tracking, Time Management, Project Analytics, …

■  Some examples: MS Team Foundation Server, Codebeamer, Plan.io

■  Wiki + tracker

□  Track + Agilo plugin Agilo (http://www.agile42.com)

□  http://ares.epic.hpi.uni-potsdam.de/swt2-agilo/{hasso|larry}/

16

Agenda


■  Git




■  Outlook



17

Application Stub


18

Application Stub


19

Application Stub

■  (Almost) no models, controllers, or views given

■  Basic UI and navigation concept is given

■  IT Systems Engineering != UI Designer

■  Share re-usable code in helpers SWT2 | Chapter 5: Getting you ready for the project | WS2010/2011

20

Agenda


■  Git




■  Outlook



21

Your next week in a nutshell

■  Project start

■  Planning meeting (SM moderates)

□  PO & teams agree on sprint goal

□  Team capacity is estimated □  PO presents 1st user story from his product backlog

□  Team writes down tasks

□  Task sizes are estimated

□  Capacity left?

□  Done

■  Architecture / coordination meeting(s)


yes

22

Agenda


■  Git




■  Outlook



23

Introduction into Testing in Rails

■  Test-driven Design

□  Design and documentation practice

□  Writing tests before writing code 1.  Write test 2.  See test fail 3.  Write simplest solution 4.  See test pass 5.  Refactor 6.  See test pass, GoTo 1

□  Red/green/refactor


24

Introduction into Testing in Rails

■  TDD tends to depend on implementation specifics

■  BDD tries to describe the behavior of the code under test

■  The same is true at application level

■  Warning:

□  You do not know what the application should do?

□  do not apply TDD / BDD

□  Instead: do a spike (proof of concept) □  Throw the code away afterwards


25

RSpec

■  “Write executable examples of the expected behavior of a small bit of code in a controlled context”

describe UserList !

do context "when first created" do!

it "is empty" do !

user_list = UserList.new!

user_list.should be_empty!

end!

end!

end!

■  When run in a shell:

UserList when first created

is empty


26

[Chelimsky et al.: The Rspec Book, 2010]

BDD cycle


27


BDD cycle


28


Directory Comparison


29

Cucumber


30

Implementing Cucumber Steps

■  rake cucumber FEATURE=features/add_author.feature

Scenario: Add a simple author!

Given I am on the authors page!

When I follow "Add author"!

And I fill in the example author!

And I press "Save"!

Then I should be on the authors page!

And there should be the example author!

And no error should occur!


31


Scenario: Add a simple author # features/add_author.feature:8

Given I am on the authors page # features/step_definitions/web_steps.rb:19

When I follow "Add author" # features/step_definitions/web_steps.rb:33

And I fill in the example author # features/step_definitions/standard_entries.rb:47

And I press "Save" # features/step_definitions/web_steps.rb:27

Then I should be on the authors page # features/step_definitions/web_steps.rb:195

And there should be the example author # features/step_definitions/standard_entries.rb:69

And no error should occur # features/add_author.feature:15

Undefined step: "no error should occur" (Cucumber::Undefined)

features/add_author.feature:15:in `And no error should occur'

1 scenario (1 undefined), 7 steps (1 undefined, 6 passed), 0m0.282s

You can implement step definitions for undefined steps with these snippets:

Then /^no error should occur$/ do

pending # express the regexp above with the code you wish you had

end SWT2 | Chapter 5: Getting you ready for the project | WS2010/2011

32



33


Feature: Add author

In order to add an author

As a user

I want to enter the details into a form and confirm

Then the author should be in the database

And I should be taken back to the authors index page

Scenario: Add a simple author # features/add_author.feature:8

Given I am on the authors page # features/step_definitions/web_steps.rb:19

When I follow "Add author" # features/step_definitions/web_steps.rb:33

And I fill in the example author # features/step_definitions/standard_entries.rb:47

And I press "Save" # features/step_definitions/web_steps.rb:27

Then I should be on the authors page # features/step_definitions/web_steps.rb:195

And there should be the example author # features/step_definitions/standard_entries.rb:69

And no error should occur # features/step_definitions/my_steps.rb:1

1 scenario (1 passed), 7 steps (7 passed), 0m0.213s


34

RSpec


35

Hello RSpec

describe "RSpec Greeter" do!

it "should say 'Hello RSpec!' when it receives the greet() message" do!

greeter = RSpecGreeter.new!

greeting = greeter.greet!

greeting.should == "Hello RSpec!"!

end!

end!

■  Given – When – Then ■  rake spec:models


36

Hello RSpec

JM:swt2_10_exercise juergen$ rake spec:models

(in /.../2010_WS_SWT2/vl2_exercise/swt2_10_exercise)

F

Failures:

1) RSpec Greeter should say 'Hello RSpec!' when it receives the greet() message

Failure/Error: greeter = RSpecGreeter.new

uninitialized constant RSpecGreeter

# ./spec/models/hello_spec.rb:5

Finished in 0.3104 seconds, 1 example, 1 failure


37

Hello RSpec

require 'spec_helper'!

class RSpecGreeter!

def greet!

"Hello RSpec!"!

end!

end!

describe "RSpec Greeter" do!

it "should say 'Hello RSpec!' when it receives the greet() message" do!

greeter = RSpecGreeter.new!

greeting = greeter.greet!

greeting.should == "Hello RSpec!"!

end!

end!


38

Hello RSpec

JM:swt2_10_exercise juergen$ rake spec:models

(in /.../2010_WS_SWT2/vl2_exercise/swt2_10_exercise)

.

Finished in 0.65165 seconds, 1 example, 0 failures

JM:swt2_10_exercise juergen$ bundle exec rspec spec/models/hello_spec.rb --format d

RSpec Greeter

should say 'Hello RSpec!' when it receives the greet() message

Finished in 0.44836 seconds, 1 example, 0 failures


39

Further Information on RSpec

■  Next lectures ■  http://rspec.info/documentation/ ■  http://rspec.info/rails/writing/models.html

■  @user.should_not be_valid ■  @user.should have(1).error_on

(:username) ■  @user.should be_valid

■  target.should satisfy {|arg| ...} ■  target.should_not satisfy {|arg| ...} ■  target.should equal <value> ■  target.should not_equal <value> ■  target.should be_close <value>,

<tolerance> ■  target.should_not be_close <value>,

<tolerance> ■  target.should be <value> ■  target.should_not be <value> ■  target.should be < 6

■  target.should == 5 ■  target.should_not == 'Samantha’ ■  target.should match <regex> ■  target.should_not match <regex> ■  target.should be_an_instance_of <class> ■  target.should_not be_an_instance_of

<class> ■  target.should be_a_kind_of <class> ■  target.should_not be_a_kind_of <class> ■  target.should respond_to <symbol> ■  target.should_not respond_to <symbol> ■  target.should have(<number>).things ■  target.should have_at_least

(<number>).things ■  target.should have_at_most

(<number>).things ■  target.should have(<number>).errors_on

(:field)


40

Agenda


■  Git




■  Outlook



41

Outlook

■  TDD

■  BDD

■  Testing in Rails

□  Unit::Test □  RSpec

□  Cucumber

□  Test doubles

□  Factories

□  …


42

Agenda


■  Git




■  Outlook



43

PO Presentation


44

Thank you for your attention!


Backup


Lego Scrum Exercise

■  Exercise should take place in positive atmosphere ■  POs really should adopt the given User Stories (except in Sprint 1) ■  If no questions by team occur during sprint,

something might be wrong ■  PO should not accept any solution (acceptance criteria has

to be met) ■  If same acceptance criteria is repeated over and over, a “Definition of Done”

might be introduced (probably with the “Street” User Story ■  Scrum Master should moderate meetings ■  Meetings have a fixed end (timeboxed)

□  At the end of a meeting, the group can decide to add a few more minutes □  BUT, it is not allowed to just overrun the meeting end!

■  The retrospective is a unique opportunity for team learning ■  Teams should vary their process – they can work alone, in teams of 2, 3, 4, ... ■  Make sure to capture the ideas, problems, etc. that come up during this

exercise – might they come up in the Software project as well?


47

Practical Examples

■  RSpec Buch ab S. 61

■  RSpec Buch bis S. 200

■  UNIT::TEST im TestReceipes Buch ist auch gut (bspw. bis S. 101)


48

Fixtures


49

Fixtures, 1:n relationship


50

Fixtures, n:m relationship


51

Fixtures

■  In spec_helper: fixtures:all!


52

Test Run


53

Setup and Teardown


54

Setup and Teardown


55

software engineering 2 (swt2) - hasso plattner...

Documents