+ All Categories
Home > Documents > Software Engineering and Architecture

Software Engineering and Architecture

Date post: 23-Oct-2021
Category:
Upload: others
View: 4 times
Download: 0 times
Share this document with a friend
of 25 /25
Software Engineering and Architecture Test-Driven Development
Transcript
Page 1: Software Engineering and Architecture

Software Engineering

and Architecture

Test-Driven Development

Page 2: Software Engineering and Architecture

What is it?

• Test-Driven Development

• It is a systematic programming technique

– Focus on

• Continued Speed

• Reliability

• It is not a testing technique, despite the name

– Tests are means, not an end in itself

– But they are sooo nice to have afterwards…

CS@AU Henrik Bærbak Christensen 2

Page 3: Software Engineering and Architecture

Systematic Programming

• TDD replaces tacit knowledge with a formulated process

– The mantra

• Clean code that works

– The values

• The four values that abstractly define what we want

– The rhythm

• The five steps in each highly focused and fast-paced iteration.

– Testing principles

• The testing principles that defines a term for a specific action to

make in each step

• Form: Name - Problem – Solution

Henrik Bærbak Christensen 3CS@AU

Page 4: Software Engineering and Architecture

The Mantra

– To ensure that our software is reliable all the time

• “Clean code that works”

– To ensure fast development progress

– To ensure that we dare restructure our software and its

architecture

• “Clean code that works”

• Clean = understandable and changeable

Henrik Bærbak Christensen 4

Clean code that works

CS@AU

Page 5: Software Engineering and Architecture

The Values

• Keep focus

– Make one thing only, at a time!

– Often

• Fixing this, requires fixing that, hey this could be smarter, fixing it,

ohh – I could move that to a library, hum hum, …

• Take small steps

– Taking small steps allow you to backtrack easily when the ground

becomes slippery

– Often

• I can do it by introducing these two classes, hum hum, no no, I need

a third, wait…

Henrik Bærbak Christensen 5CS@AU

Page 6: Software Engineering and Architecture

The Values

• Speed

– You are what you do! Deliver every 14 days!!! Or two hours…

– Often

• After two years, half the system is delivered, but works quite in

another way than the user anticipate/wants…

– Speed, not by being sloppy but by making less functionality of

superior quality!

• Simplicity

– Maximize the amount of work not done!

– Often

• I can make a wonderful recursive solution parameterized for

situations X, Y and Z (that will never ever occur in practice)

Henrik Bærbak Christensen 6CS@AU

Page 7: Software Engineering and Architecture

The Iteration Skeleton

• Each TDD iteration follows the Rhythm

• (6. All tests pass again after refactoring!)

Henrik Bærbak Christensen 7CS@AU

Page 8: Software Engineering and Architecture

The Rhythm: Red-Green-Refactor

• The Rhythm

Works part

Clean part

Introduce test

of delta-feature

Implement

delta-feature

that does not

break any

existing code

Improve

code

quality

Time

CS@AU Henrik Bærbak Christensen 8

Page 9: Software Engineering and Architecture

The Three Starter Principles

CS@AU Henrik Bærbak Christensen 9

Page 10: Software Engineering and Architecture

Enough…

Learning by Doing…

Page 11: Software Engineering and Architecture

You are all employed today

• Welcome to PayStation Ltd.

• We will develop the main software

to run coin-operated pay stations

• [Demo]

Henrik Bærbak Christensen 11

Page 12: Software Engineering and Architecture

Case: Pay Station

• Welcome to PayStation Ltd.

• Customer: AlphaTown

• Requirements

– accept coins for payment

• 5, 10, 25 cents

– show time bought on display

– print parking time receipts

– US: 2 minutes cost 5 cent

– handle buy and cancel

Henrik Bærbak Christensen 12

Page 13: Software Engineering and Architecture

Stories

Henrik Bærbak Christensen 13

Page 14: Software Engineering and Architecture

Design: Static View

Henrik Bærbak Christensen 14

• For our purpose the design is given…

– Central interface PayStation

Page 15: Software Engineering and Architecture

My Testlist

• From the book

CS@AU Henrik Bærbak Christensen 15

Page 16: Software Engineering and Architecture

And on…

CS@AU Henrik Bærbak Christensen 16

Page 17: Software Engineering and Architecture

Central Principles Overview

Page 18: Software Engineering and Architecture

Refactoring

• Fix your broken windows

– Clean up now or your code

will deteriorate quickly!

CS@AU Henrik Bærbak Christensen 18

Page 19: Software Engineering and Architecture

CS@AU Henrik Bærbak Christensen 19

Page 20: Software Engineering and Architecture

CS@AU Henrik Bærbak Christensen 20

Page 21: Software Engineering and Architecture

CS@AU Henrik Bærbak Christensen 21

Page 22: Software Engineering and Architecture

Outlook

Tests as Specifications

Page 23: Software Engineering and Architecture

Insight

• An early insight was that the tests are actually a

specification of the requested behaviour

– Aka a requirements specification!

• What if costumers could write them themselves !?!?

• Gave rise to much experimentation

– Behaviour-Driven Development

CS@AU Henrik Bærbak Christensen 23

GWT/Gherkinnotation

Page 24: Software Engineering and Architecture

Spock

• A lot of frameworks were developed

– Many are... Well... IMO somewhat cumbersome to use

• Spock I find is pretty easy to get going, though

– Only problem, you code in groovy, not Java...

CS@AU Henrik Bærbak Christensen 24

Page 25: Software Engineering and Architecture

My Take

• FRS §5.12,

– I write my GWT’s as comments, marking the 3 sections

CS@AU Henrik Bærbak Christensen 25


Recommended