Embed Size (px)
Citation preview
Или как да настъпваме по- малко мотики
Continuous Integration(CI, Sonar и TDD)
Защо писането на софтуер е трудно ?Бизнесът е сложенИзискванията се променят
честоКлиентът не знае какво искаВсичко трябва да стане
ASAP
Как можем да подобрим ситуацията Наемаме още хораНамаляваме обхвата на
проектаПроменяме
методологията на работа
Какво е CI
Обикновено програмистите работят така:
Разработчикът пише приложениеQA тества приложението (може би)Приложението отива при клиента
И ...
Ядосан клиент
Как работим при CI
1. Програмистът разработва част от приложението
2. Програмистът разработва тест за кода си3. Кодът отива в Система за управление на
сорса (версиите)4. Билд сървърът взема кода и пуска тестове
срещу него5. При проблем се изпраща съобщение до
програмиста / мениджъра6. Отиваме на стъпка 17. Ако всичко е Ок, отиваме да пием бира
?Защо да си
правим труда
Отговорът
1. CI предполага подобряване гранулярността на задачите
2. CI ни задължава да имаме достатъчно пълни и работещи тестове, независимо от промените на клиента
3. CI позволява на разработчика/мениджъра да е сигурен в своя продукт
4. И в крайна сметка понеже софтуерът ни работи имаме и ...
Щастлив клиент
Архитектура на CI
Какво включва билда
Сорс кодБиблиотекиСкриптове за БДТестове и тестови скриптовеСкриптове за билдванеФайлове с настройки и др.Всичко се пази във VCS (без
библиотеките)
Характеристики на CI билда
Билдът е напълно автоматиченБилдът винаги взема код от VCSИзходът (освен при компилационни
грешки) винаги е изпълним кодИнформацията относно състоянието
на билда се изпраща на заинтересованите страни
Тестове изпълнявани от CI Unit тест – тества малки парчета от
кода със специфична функционалност Integration тест – проверява работата на
различните компоненти заедно Системен (функционален) тест – тества изцяло
функционалността на системата (най-често през UI)
Load (Stress) тест – проверява държанието на системата при различни натоварвания
Security тест – анализира приложението за дупки в сигурността
Статичен анализ на кода
CI може лесно да изпълнява проверка за честно срещани грешки, излишна сложност и т.н.
Инструменти:CodePro AnalytiXFindBugsCheckstyleCoberturaSonar
Какво още ни дава CI
Автоматичен deployment на кода
CI на базата от данни
Обратна връзка – IM, Email, SMS, Twitter
Нека да обобщимCI позволява бърза обратна връзка
при промениКодът е в завършено състояние, можем да
направим release по всяко времеПриложението стига по-бързо до QAДава възможност на екипа да се занимава
с по-интересни нещаЗадържа добрите инженери във фирматаRelease early, release often
Нека да обобщим
Прави по-лесно откриването на проблеми, веднага щом се появят
При много-платформени приложения позволява намирането на бъгове, специфични за отделните платформи
Намалява несигурността на екипа в продукта и премахва нежеланието за промени
Демо
Какво е TDD
Начин на работаКратки итерации за developmentTFDПозволява лесна промяна на
кодаНамалява броя на проблемите в
приложението
Начин на работа
1. Помислете върху дизайна на кода2. Добавете тест3. Пуснете тестовете и вижте дали новият
тест “гърми”4. Напишете кода, така че тестът да мине5. Пуснете тестовете и проверете дали
минават6. Рефакторирайте7. Обратно на 1
Каква е ползата ?
Изчистваме изискванията на функционалността
Изисква да пишем слабо свързани компоненти
Описваме дизайна на кода чрез теста Имаме завършен regression suite
А какви са минусите?
Необходима е подкрепа от мениджмънта – иначе изглежда, че пилеем време
Трябва да поддържаме и вече написаните тестове
Обикновено един и същи човек разработва и теста и кода (възможни са еднакви грешки) – Pair Programming ?
Многото минаващи тестове могат да подведат мениджмънта и да намалят останалото тестване
Кога TDD е излишно
Няма дисциплина Няма се ясна визия какво трябва да прави
системата Нямате идея как да направите кода слабо
свързан Мениджмънта не се интересува от
качество, а само да пусне продукта Кода няма да се поддържа При поддръжка на стар код/ стари системи
Ресурси
Test Driven-- Practical TDD and Acceptance TDD for Java Developers http://www.manning.com/koskela/
Unit testing with mock objects - http://www.ibm.com/developerworks/library/j-mocktest.html
Hudson Wiki - http://wiki.hudson-ci.orgSonar Wiki -
http://docs.codehaus.org/display/SONAR/Documentation
Презентация за TDD на Адриан Митев – http://www.slideshare.net/adrianmitev/testdriven-development-6014243
