BDD for RIAs with JavaScript

2013 Workshop Tour

Carlos Ble carlosble.com

@carlosble

Warning

This workshop is very demanding so please:

● Ask anything you need.● Give me feedback.● Take notes.● Pay attention.● Be responsible.● Get ready to share code with others.

Effective communication

Your only goal when communicating should be

to … Communicate!Don't talk or write to...

● Demonstrate how smart you are● Convince others ● Fight others ● Avoid the uncomfortable silence● Think out loud

No one is more important than you, and you are not more important than anyone else. What others think about you, is

not your business.

The seven rules of Angel Lafuente

1ª. Nunca la palabra antes que el pensamiento. 2ª. No interrumpir la frase o idea. 3ª. Frase breve. 4ª. Mirada interpelante. 5ª. Gesto libre. 6ª. Silencios. 7ª. Velocidad posible y adecuada

Those who master silence, master spoken word.

http://www.ulpgc.es/hege/almacen/download/48/48279/manual_del_curso.pdf

Listen to yourself: use your common senseBe honest to yourself because your intuition and feelings are telling you all the time what is

more appropriate in every situation.

Pay attention to your gut feelings because they don't cheat you.

Listen carefully to others to be empathetic to them.

Do what you know you ought to do.

Where are you standing?

Is everything OK with you and your environment?

● Breath● Sleep well

● Eat well● Work out

● Workplace environment must have good conditions● Try to learn about yourself

There are several techniques to help you practice self-control and self-discovery :

● Meditation● Yoga

● Martial arts● Team sports

● Extreme sports● And much more!

Where are you standing?

Is everything OK with you and your environment?

● Breath● Sleep well

● Eat well● Work out

● Workplace environment must have good conditions● Try to learn about yourself

There are several techniques to help you practice self-control and self-discovery :

● Meditation● Yoga

● Martial arts● Team sports

● Extreme sports● And much more!

Be a good team player

Don't make assumptions

Don't take it personally

Do your best

Be precise and specific with your words

See also the Core Protocols

BDD is a set of values and practices

Build the thing right

dannorth.net/introducing-bdd/

dannorth.net/whats-in-a-story/

chrismdp.com/2013/01/bdd-is-not-cucumber/

[Over]simplification: specification by example + outside-in TDD

Lean development and Impact Mapping

Build the right thing, avoid waste

en.wikipedia.org/wiki/Lean_software_development

impactmapping.org/drawing.php

What, not how: the amazing happens when you just write the minimum code

Case Study: LiveTeamApp.com

● No password or registration required.● Group chat and individual chat rooms.● GUI tailored to users according to their feedback.● Pomodoro integrated with team monitor and and chat.● New features are delivered in a matter of hours.● Everything is covered by tests.

Remember: Just make your acceptance tests pass deferring any other decision as much as

possible.

LiveTeamApp

The specifications workshop

50-70% of the defects are in the requirements...

● Focus on what, not how● Avoid GUI details in the examples● All the roles together in the workshop:

● Facilitator● Stakeholders● Business Analysts● Product Owners● Testers● Developers

● Face to face conversation● Time, an important investment:

● 2 hours for a week sprint seems reasonable

Good books out there

● Bridging the communication gap● Specification by Example

● Impact Mapping● ATDD by Example

● The cucumber book

Starting with the user story

Title (one line describing the story)

Narrative:As a [role]

I want [feature]So that [benefit]

Acceptance Criteria: (presented as Scenarios)

Scenario 1: TitleGiven [context]

And [some more context]...When [event]

Then [outcome] And [another outcome]...

Exercise

The specification workshop

Wait a moment:Three types of JavaScript

➢ With TDD➢ Without TDD

➢ For Frameworks

BDD for RIAs: the process

A Rich Internet Application is very different from a Website!

App core: Passive View pattern

Outside-in: Blue: test-driven with unit tests, using test doubles.

Green: test-driven with unit tests, using test doubles.Pink: test-driven with integration tests.

Outside-in development

Good understanding of test doubles:● Stubs: programmed to return answers.● Spies: will remember calls.● Mocks: will fail on unexpected calls.● Fakes: almost like the real system, just faster or repeatable.

How to write scenarios where some objects don't exists already? Remember the UML :-)

Key rules: ● Do not mock artifacts you don't own.● Use stubs for queries and mocks/spies for actions.

Exercise: the flow

1. Connecting the Business API with the service. 2.Connecting the UI with the service.3.Implementing the service.4.Implementing the interactor.5.Implementing the databinder.

All of them are UNIT TESTS

Advice: let the team follow code changes

● Initialize a code repository for the exercises (Git, Mercurial, or whatever you prefer).

● Make commits small enough that just by looking at the “diff” anyone can understand what the change is.

● This usually means, no more than 10 lines of code.

● Try to commit on red, on green, and eventually on refactor.

● This is a great way to document code changes.

Exercise: the integration

●TextBox Widget Implementation

●Storage implementation

Architecture review

Patterns:● Passive View

● Factory● Wrapper● Observer● Pub/sub

● Singleton

Non-emergent architecture:I18n, fault tolerance, security,

scalability, SEO, routing, contents...