14. Agile манифест
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
15. BDD
Behavior-driven development (or BDD) is an
agile software development technique devised
by Dan North as a response to the issues he
encountered whilst teaching Test-Driven
Development:
● Where to start
● What to test and what not to test
● How much to test in one go
● What to call the tests
● How to understand why a test fails
18. Хороший менеджер
● Должен обладать способностью понимать
людей разного склада ума (от
разработчиков, до бизнес-заказчиков) и
умение помогать переводить мысли с
языка одних на язык других
● Умеет не ссать и не ныть! Даже когда ссыкотно и ныть хочется.
● Знает чем отличается Quality Assurance
от тестирования
● Понимает, что разработанный софт это
не конец проекта, а всего лишь начало. И
знает чего
http://cartmendum.livejournal.com/93084.html
24. Cucumber
● Средство для автоматизированного
тестирования
● Позволяет описывать поведение системы
на естественном языке
● Является основным инструментом в
Behaviour Driven Development (BDD)
25.
26. План огурец
1. Опишите поведение системы на естественном
языке(Напишите сценарий поведения)
2. Опишите шаги сценария на языке
программирования
3. Запустите тесты и убедитесь, что они не
проходит
4. Напишите код, который реализует поведение,
описанное в тестах
5. Запустите тесты снова и убедитесь, что
некоторые тесты начали проходить
6. Повторите 2-5 шаги, пока все тесты не начнут
проходить
7. Повторите 1-6 шаги, пока не закончатся деньги
у заказчика
27. Feature: Title
In order to [Business Value]
As a [Role]
I want to [Some action]
Scenario: Title
Given [Context]
When [Action]
Then [Outcome]
28. # language: ru
Функционал: Сложение чисел
Чтобы не складывать в уме
Все, у кого с этим туго
Хотят автоматическое сложение целых чисел
Сценарий: Сложение двух целых чисел
Допустим я ввожу число 50
И затем ввожу число 70
Если я нажимаю "+"
То результатом должно быть число 120
29. Допустим /ввожу число (d+)/ do |число|
calc.push число.to_i
end
Если /нажимаю "(.*)"/ do |операция|
calc.send операция
End
То /результатом должно быть число (d+)/ do |результат|
calc.result.should == результат.to_f
End
33. Scenario: Create Post
Given I am a registered User
And I have signed in
When I go to Create Post Page
And I create a Post and Publish it
Then I should see the Post in the Index
Page
34. Scenario: Create a Post
Given I am a registered User with name "Chuck", email
"chuck@Norris.com" and password "123456"
And I sign in as "chuck@Norris.com/123456"
When I visit Create Post Page
And I fill up Title as "Best Post"
And I fill up Content as "Chuck Norris counted to infinity
- twice."
And I publish the Post
Then I should see message "Post was successfully
created."
And I should see post in the index page
35. Scenario: Artist creates an art work
Given I am a registered artist
And I am on my dashboard
And I follow "Add an artwork" within "#dashboard"
When I fill in "Title" with "The Arnolfini Portrait"
And I fill in "Description" with "A nice portrait."
And I select "Painting" from "Category"
And I attach "arnolfini.jpg" to "Select picture"
And I press "Create"
Then I should see "The Arnolfini Portrait was
successfully added to your art collection."
36. Scenario: Artist creates an art work
Given I am a registered artist
And I follow the add new artwork link from the
dashboard
When I fill the form with the artwork data
And I upload a picture
Then I should see a confirmation message telling me
that the artwork was added to my collection
39. web_steps_warning.txt
# This file was generated by Cucumber-Rails and is only here to get
you a head start
# These step definitions are thin wrappers around the
Capybara/Webrat API that lets you
# visit pages, interact with widgets and make assertions about page
content.
#
# If you use these step definitions as basis for your features you will
quickly end up
# with features that are:
#
# * Hard to maintain
# * Verbose to read
#
# A much better approach is to write your own higher level step
definitions, following
# the advice in the following blog posts:
#
# * http://benmabey.com/2008/05/19/imperative-vs-declarative-
40. Good practices
● Don’t use “Background” to set up complicated state
unless that state is actually something the client needs
to know.
● Keep your scenarios short.
● Make your scenarios vivid.
● Declare, not implement
44. Profit
● Разговор на одном языке
● Четкие и понятные требования
● Уверенность
● Метрика
● Вовлеченность в работу
● Живая документация
● Уверенный рефакторинг
45. Ошибки
● Нет времени
● Хлопотно
● Требования быстро меняются
● Оформление часто меняется
● Идеальный сценарий
● Cucumber == BDD