Архив рубрики: Разработка

Acceptance, functional, unit. В таком порядке.

Вы решили написать тесты? Отлично! С чего начнем?

Блин!

Ваш проект полон «костылей» и кода, которые делают тестирование сложным или даже почти невозможным, а если вы еще и новичок в тестировании. Что делать?

Очень просто! Начните с Acceptance-тестов, далее functional-тесты и только в самом конце unit-тесты!

Приемочные (acceptance) тесты очень похожи на Behat-тесты, где вы тестируете конкретные пользовательские истории и поведение. Приемочные тесты проверяют весь цикл от веб-сервера до базы данных и обратно, они способны выявить множество ошибок приложения.

Как только вы напишите приемочные тесты — можно приступать к рефакторингу кода приложения и написанию функциональных (functional) тестов, которые проверяют взаимодействие отдельных компонентов. Дальнейший рефакторинг делает возможным написание модульных (unit) тестов — тестов, которые проверяют компоненты приложения отдельно друг от друга.

Тестирование это не «все или ничего»! Начните с простейших тестов, которые охватывают все части приложения и тестируют верхнеуровневую логику.

Начните писать тесты уже сегодня!

Приходите, научу писать тесты….

Тренажер по Python

Все же решил немного освежить свои скромные знания по Python.
Долго искал хорошие материалы/курсы/онлайн тренажеры.

Про полную лажу на рынке Российского онлайн-образования не писал только ленивый. «СкилбоСсы» и прочие «ГикБрайсы» выжгли поле, срубили тонны денег и сломали весь рынок =) Но об этом в следующий раз.

В итоге нашел «хайперскил» от JetBrains и старый добрый «хекслет«

У обоих довольно хорошие программы по питону.

Свойство только пишется, но не читается.

В PhpStorm есть отличная штука — свойства класса, которые пишутся (инициализируются в конструкторе), но не читаются — подсвечиваются.
Очень удобно рефакторить, например, легаси контроллеры, в которых инжектится куча сервисов, но в процессе эволюции часть из них перестает использоваться.
Открыл, увидел подсветку и спокойно все выпилил.

А если хотите, чтобы кто-то порефакторил за вас — приходите за разработкой к нам =)

База знаний в saas-проекте

Любой интернет-проект, а особенно если это saas-сервис, должны иметь хорошую документацию для пользователей. На эту документацию должны ссылаться специалисты технической поддержки при работе с клиентами, ссылки на эту документацию должны быть аккуратненько и уместно размещены в личном кабинете сервиса (или на сайте).

Небольшой список требований к такой базе знаний и движкам, для их построения:

  1. Актуальность. Информация всегда должна быть актуальной. Поменялся интерфейс системы — меняйте скриншоты в базе знаний. Добавили новый функционал — добавьте информацию об этом в базу знаний.
  2. Структурирированность. Информации о продукте становится все больше и больше. Правильное ее структурирование обеспечит удобство использования.
  3. Поиск. Он просто должен быть и быть классным +)
  4. Простота ведения. Интерфейс администратора/оператоа должен быть элементарным (привет, конфлюенс!)

Ну и хватит пока.

Под требования выше подходит практически любая современная CMS или вики-движок, имеются и специализированные решения.

В голове рождаются мысли о написании такого движка на Symfony, постараюсь их отогнать =)

BitBucket прекращает поддержку Mercurial

Когда-то давно я пришел на Bitbucket именно из-за поддержки и Git и Mercurial.

Времена идут, продуктовые стратегии меняются, старое выпиливается.

Самое главное, что пользователям дается время свалить с битбакета или мигрировать на Git.