Test-driven developmentAnd how we do it at WIX

Mantas IndrašiusSoftware EngineerWIX.COM

Agenda

● Tests overview● Test-driven development (TDD)● Let’s see it in action (demo)● Kickstarting a project using TDD● How we do it in WIX

Tests overview

Why writing tests

● Reliability● Freedom of change● Tests as specification● Design hints for free● Saves time and cost● Instant/fast feedback

Developer feedback

Feedback cycles

● Unit tests - a second or two● Acceptance test - 1-10 minutes● Manual testing / using debugger - 1-30 minutes● Continuous integration - 10-60 minutes● Peer review - few hours● QA - from few hours to days● Production - days, weeks or months● And we do it in multiple iterations

Feedback from process

The Word of Wisdom

Fail as fast as you can!

Levels of testing

● Acceptance - does the whole system work?● Integration - does our code work with 3rd

party?● Unit - do our objects do the right thing?

Pyramid of developer tests

Unit tests

● We set requirements for object behavior● We set preconditions and expectations● Test behavior with different input

arguments● We use object mocks to isolate the class

under test

Unit tests

Unit tests

Acceptance testing

TDD(Test-driven development)

What is TDD?

● It’s a development process of very short development cycles based on a rapid feedback

● It’s a design activity● It’s a design support tool● It’s a safety net of regression coverage

The basics of TDD process

● Write a test● Run all tests and see the new one fails● Write minimal amount of code for the test

to pass● Run all the tests and see them pass● Refactor code to acceptable standards

Red - Green - Refactor

The Golden Rule of TDD

Never write a new functionality without a failing test

The Bigger Picture

● Write a failing acceptance test and keep it so

● Go to the class level and do TDD with unit and/or integration tests

● Once finished, check the acceptance test● If it’s still not passing, continue with

changes in the class level

The Bigger Picture

Let’s see it in actionDemo

Why acceptance tests are not enough

● Acceptance tests are slow● They are not suitable to test edge cases● They don’t help maintaining a good design● They are not allowed to have access to the

internal components of the system

How TDD helps us?

● We learn to grow software incrementally● We learn to design in top-down approach● We write just enough code for a feature● We are guided to maintain a sustainable design● We don’t need UML in software design● At any given time we have a ready to deploy

system● We always have the most up-to-date

specification

Agile loves TDD

● Incremental development● Short feedback loop● Working software over documentation● There is no component someone owns● Quality first

Kickstarting a projectUsing TDD

The first step: The Walking Skeleton

● The Goal: Build the infrastructure● Choose the minimal system feature to focus

on infrastructure● Infrastructure should include all the

essential anticipated components● We should learn how to build and deploy● Pass the first acceptance test

The Walking Skeleton on legacy

● The Goal: Build the infrastructure● Choose the simplest existing system feature

and focus on building the infrastructure● Infrastructure should include all the

essential anticipated components● Pass the first acceptance test● Cover the other cases one-by-one

The context of the first step

Uncertainty in test-first and test-later

How we do it in WIX

What do we do in WIX

● Website editing and publishing platform● User account / business management

system● App Market● Hundreds of small applications in the

market● Business verticals: hotels, reservations,

music, photography etc

Scale of WIX

● More than 57,000,000 users● 1.2PB of data (1.5TB per day)● 900 servers in 3 data centers● 3 clouds (Google, Amazon, Azure)● 50000 dynamic requests per minute● More than 900 employees

Engineering in WIX

● WIX is a company with developer-centric approach

● Excellence of Engineering is our priority to adding new features

● Every developer in WIX is also a DevOp● Service oriented architecture● We do continuous delivery

TDD at WIX

● We believe in TDD, we start learning it from the first day at work

● Client-side and server-side do it separately in their isolated ecosystems

● We approach TDD from E2E rather than acceptance testing

● TDD empowers us to practice the Continuous delivery approach

Continuous delivery

Our Concerns

● Continuous integration● Backwards and forwards compatibility● Feature oriented design● Experiments● Data inconsistency

Tools

● TeamCity - continuous integration and release

● LifeCycle - a custom built tool to manage the project lifecycles (version management, delivery)

● Artifactory - storage for artifacts● Chef - deployments / server provisioning

Client-side infrastructure

● AngularJS for building the rich UI● Grunt for running the build (incl. tests)● Jasmine for describing test behavior● Karma + PhantomJS for testing units● Selenium with Protractor for E2E or

acceptance tests● SauceLabs for cross-platform testing

Client-side build

● Run the unit tests with Karma & PhantomJS

● Start a fake API server on NodeJS● Start the controlled browsers● Run the E2E test suite against them● Clean up & deliver the artifact

Server-side infrastructure

● Scala/Java for server applications● Maven as a build tool● specs2/JUnit for describing the test

behavior● JMock/Mockito for testing units● Custom HTTP test-kit for HTML/JSON

matching

Server-side build

● Run unit tests● Setup the embedded environment (MySQL,

MongoDB, Cassandra)● Start the fake 3rd party services● Start the server under test● Run the E2E test suite against it● Clean up & deliver the artifact

Release process in WIX

Ačiū!Any Questions?