Sometimes we have a task that causes a feeling of fear. This fear appears because the task has something new, something in what I am not experienced yet.
My list about how to solve this and defeat such fears:
Relax and think why you have a fear
Ask your supervisor/teammate for advice/support
Find some examples of solutions for a similar task
Prepare first version of solution and discuss it with somemone (superviser, client, teammate)
Update your solution according to feedback from them and go back for review with your supervisor/teammate
Steps 4-5 are repeatable unless you have a proper solution.
All of us made something in the first time and the fear is a normal for everyone.
Очень классное приложения для прокачки английского, я уже про него писал ранее. И вот мое новое достижение, я прошел все темы. Теперь буду апгрейдить уровни по каждой из них и учить испанский 🙂
Все бесплатно и качественно, удобно что можно прокачивать даже speaking навык, хотя я эту фичу выключил для себя 🙂
И да, можно учиться через веб и мобилку. Жаль, что нет видео уроков…
Возникла у нас в компании проблема с превью документов, использовали мы для превью на портале всем известную тулзу от гугла. Но с ней были проблемы, у пользователя не всегда рендерился документ(видимо лимиты по количеству вызовов) и когда он рендерился, то бывало, что внешне превьюсильно отлиалосьот оригинала. Поэтому было решено разработать превью документов на нашем кор. портале с использованием уже имеющегося у нас Office Online.
Бывает возникает такая ошибка: Unique violation: 7 ERROR: duplicate key value violates unique constraint “table_pkey”. Казалось бы ключ с автоинкрементом и такого быть не должно, но поскольку значение следующего ID берется из последовательности, то возможно ее стоит пересчитать, а сделать это можно таким sql-запросом:
SELECT setval(pg_get_serial_sequence('table_name', 'id'), MAX(id)) FROM table_name;
где table_name – имя таблицы, id – primary key таблицы
Зарегистрировался на сервисе hackerrank.com. Что это за сервис?
HackerRank — это социальная платформа, которая предлагает задания разной сложности по программированию. Запущена платформа была в 2012 году. Сейчас аудитория проекта насчитывает около полутора миллиона пользователей. Статистику по результатам решений заданий своими пользователями ресурс регулярно публикует в виде рейтинга по 50 странам. (источник: https://geektimes.ru/post/280074/)
Хочу отметить удобный интерфейс и интересные задачи, рекомендую для тех, кто хочет держать себе в форме 🙂
Сегодня хочется немного рассказать о написании тестов в проектах написанных на Golang.
В плане тестирования в Go подход очень простой а точнее примитивный. Дело в том, что Go за тем как писать и организовывать тесты разработчик должен следить сам, т.е. вся ответственность на разработчике приложения 🙂
Это в свою очередь приводит к тому, что привычного инструментария для тестирования не так много, но зато он уже есть в коробке.
А вот что есть в этой самой коробке и как это можно приукрасить я и хочу рассказать.
Первый простой тест
Задача: Написать функцию, которая прибавляет к целому числу два и возвращает его в качестве результата.
В первую очередь мы пишем тест. Файл с тестом назовем numberator_test.go, это первое что нужно знать, все тесты в go должны быть в файлах с постфиксом _test.go.
Вот простейший пример теста:
package numberator
import "testing"
func TestNumberIncrement(t *testing.T) {
// если результат выполнения
// функции не равен сумме 5+2
// то добавляем ошибку
if NumberIncrement(5) != 5+2 {
t.Error("Error! NumberIncrement(5) != 5+2")
}
}
Думаю суть теста понятна и не требует дополнительных объяснений.
Как же теперь нам запустить наш тест, делается это очень просто командой go test:
go test ./
Улучшаем наш тест
Наш тест выполняется и успешно падает, вроде бы все хорошо, но хотелось бы сделать наш тест не только работающим и выполняющим свою функцию но и более приятным для нас разработчиков.
Поставить его очень просто: go get github.com/stretchr/testify
Перепишем наш тест с помощью этого пакета:
package numberator
import (
"github.com/stretchr/testify/assert"
"testing"
)
func TestNumberIncrement(t *testing.T) {
// задаем здесь наше правило
// результат NumberIncrement(5) должен быть равен 5+2
assert.Equal(t, NumberIncrement(5), 5+2, "NumberIncrement(5) != 5+2")
}
Теперь наш тест стал понятнее и сам говорит о своих ожиданиях, не так ли?
В этом же пакете есть много дополнительных методов для улучшения наших с вами тестов. Со всеми возможностями этого пакета можно ознакомиться на https://godoc.org/github.com/stretchr/testify.
Разработка через тестирование (англ. test-driven development, TDD) — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам. Кент Бек, считающийся изобретателем этой техники, утверждал в 2003 году, что разработка через тестирование поощряет простой дизайн и внушает уверенность (англ. inspires confidence).
Кстати, рекомендую прочитать книгу о TDD самого Кента Бега(http://www.ozon.ru/context/detail/id/1501671/). О том для чего и когда использовать TDD я в этой заметке писать не буду, т.к. я думаю, что это достаточно очевидный момент и как правило вопрос возникает как к этому подходу разработки перейти и как его успешно внедрять.
Workflow
Ниже на рисунке представлен процесс разработки программы в стиле TDD.
процесс разработки программы в стиле TDD
Начинается весь процесс всегда с написания тестов и далее двигаемся по стрелочке:
1. Написание теста, без написания логики программы, которую мы проверяем в тесте.
2. Запуск теста и проверка того, что тест красный, т.к. у нас нет реализации тестируемой части(если тесты зеленые – значит тесты ничего не проверяют и их нужно переписать)
3. Пишем код, который делает тесты зелеными(минимальный код, а точнее любой корректно работающий код, который сделает тесты зелеными)
4. Запускаем тесты и проверяем, что они зеленые
5. Рефакторинг, мы переписываем наш "говнокод" для озеленения тестов, так, чтобы он был работающим и хорошо пахнущим не только для тестов, но и для нас.
Проблема первого теста
Исходя из собственной практики на первых этапах самое сложное это начать писать первый тест, до реализации тестируемого кода и здесь я вижу два приема:
1. Написать сначала интерфейс, затем переходить к тесту. Это позволит начать переход к TDD и при этом не слишком "тупить" над тем, что и как тестировать, т.к. часть кода вы уже будете писать до теста и в голове уже будет небольшое понимание того, что тестировать. Ну а как привыкните – начнете писать тесты сразу.
2. Это писать сначала самый короткий, т.е. минимальный и общий тест. Собственно это и есть праведный путь TDD. Таким образом дизайн программы будет строиться по циклу через тесты, с каждой итерацией вы будете добавлять тесты и код.
Проблема плохого дизайна
Часто такое бывает, что есть желание перевести проект на TDD и жить хорошо, но оказывается так, что текущая ситуация с дизайном не позволяет перевести весь проект на TDD, на практике иногда ине всегда возможно в разумные сроки перенести весь проект на TDD. В связи сэтим разумно этого не делать, но естьвсе таки несколько вариантов для того, чтобы начать использовать TDD и в таком проекте:
1. Писать проект заново, особенно если в пользу этого уже есть какие-нибудь и другие предпосылки.
2. Выделять из проекта отдельные компоненты и тестировать их. Этот вариант подходит для проектов с не слишком НЕудачным дизайном.
3. Использовать TDD только для новых изменений кода и со временем весь проект сможет перейти на TDD. Этот вариант на мой взгляд самый универсальный.
Заключение
В общем и в целом считаю, что TDD это хороший способ улучшить стабильность и надежность своего кода и даже при написании небольших приложений это позволяет снизить количество ошибок в приложении многократно. Как минимум это стоит попробовать.