Comments 23
В течение нескольких часов выложу куда-нибудь оригинал в PDF, чтобы было легче ориентироваться в тексте и не нужно было искать его в гугле.
Здесь находится стандартный комментарий о необходимости знания английского языка для работы в сфере IT.
И комментарий о спорной правовой основе для осуществления данного перевода.
И комментарий о спорной правовой основе для осуществления данного перевода.
Очевидно, в первой части своего комментария Вы имели в виду, что перевод на русский язык будет бесполезным. Не могу согласиться. Многие читают русский текст значительно быстрее, чем английский и они хотели бы иметь книгу на русском языке. Возможно, я ошибаюсь, и идея загнется. Ну что же, в любом случае, попробовать стоило.
На счет спорной правовой основы, к сожалению, Вы правы. Пока сам не знаю, что из этого получится.
Если честно, я думаю, что никому до этого нет дела, по большому счету. Также я надеюсь, что некотрые люди купят эту отличную книгу (возможно, в других обстоятельствах они этого не сделали бы).
На счет спорной правовой основы, к сожалению, Вы правы. Пока сам не знаю, что из этого получится.
Если честно, я думаю, что никому до этого нет дела, по большому счету. Также я надеюсь, что некотрые люди купят эту отличную книгу (возможно, в других обстоятельствах они этого не сделали бы).
Основная проблема с введением тестирование — кажущаяся сложность. Это же жуть 360 страниц о том, что можно вместить на одной, а для практики можно открыть любой популярный проект на гитхабе, а лучше тесты к компоненту используемому в проекте.
Со стажёром за пол часа разобрали теорию и написали первый тест на phpunit. Ещё час потратили на моки, они зашли сложнее. На следующий день он уже самостоятельно два своих класса обложил тестами, при этом зарефакторил нетестируемые участки.
Осилив же 360 страниц воды и лучших практик, человек только запутается прежде, чем напишет первый тест. Особенно, когда примерами служат абстрактные калькуляторы, вместо компонентов используемых в реальных проектах.
Со стажёром за пол часа разобрали теорию и написали первый тест на phpunit. Ещё час потратили на моки, они зашли сложнее. На следующий день он уже самостоятельно два своих класса обложил тестами, при этом зарефакторил нетестируемые участки.
Осилив же 360 страниц воды и лучших практик, человек только запутается прежде, чем напишет первый тест. Особенно, когда примерами служат абстрактные калькуляторы, вместо компонентов используемых в реальных проектах.
А у нас на большом проекте написано много тестов, только пользы от них — никакой. Очень надеюсь, когда дочитаю книжку, у меня будут какие-то представления, позволяющие принять решения в условиях конкретного проекта (что тестировать, а что — нет, как организовать тесты, какой должна быть инфраструктура для тестов и т.д.)
Могу посоветовать хорошую книжку — xunitpatterns.com/ (на сайте, кстати, есть часть содержания)
И серию вебкастов let's play tdd www.jamesshore.com/Blog/Lets-Play/
И серию вебкастов let's play tdd www.jamesshore.com/Blog/Lets-Play/
Вы неверно имеете ввиду не введение тестирования — а введение модульных тестов. Думаю разницу вы из такой книги легко почерпнете.
Просто элементарный модульный тест написать справиться и ребенок. Для этого действительно подойдет простая статья.
Но в жизни такие элементарные вещи встречаются редко. Как правило модульные тесты очень сильно отличаются от того, что есть в простейших туториалах (работа на языке моков, подготовка внешнего окружения, анализ кавереджа, изменение архитектуры системы для тестирования нетестируемых классов, методов, например изоляция блоков кода для тестирования). И с такими вещами приходится иметь дело постоянно. Редко так бывает, что можно на проекте сразу начать с какого то очень простого теста.
И очень быстро при написании тестов возникает очень много других серьезных проблем — как называть тестовые методы, что покрывать, а что нет, какого они должны быть размера и как реюзать в них функционал и т.д. Глупо самому все это проходить на своей шкуре. Если есть методики.
То есть уметь написать элементарный тест — это по сути понимание что такое модульный тест в принципе. И все. До умения писать эффективные модульные тесты в реальной боевой обстановке отсюда ой как далеко. А неэффективные могут и не окупится на проекте.
Хоть сам книжки не часто читаю — но в принципе — это хороший путь разобраться во всем этом.
Просто элементарный модульный тест написать справиться и ребенок. Для этого действительно подойдет простая статья.
Но в жизни такие элементарные вещи встречаются редко. Как правило модульные тесты очень сильно отличаются от того, что есть в простейших туториалах (работа на языке моков, подготовка внешнего окружения, анализ кавереджа, изменение архитектуры системы для тестирования нетестируемых классов, методов, например изоляция блоков кода для тестирования). И с такими вещами приходится иметь дело постоянно. Редко так бывает, что можно на проекте сразу начать с какого то очень простого теста.
И очень быстро при написании тестов возникает очень много других серьезных проблем — как называть тестовые методы, что покрывать, а что нет, какого они должны быть размера и как реюзать в них функционал и т.д. Глупо самому все это проходить на своей шкуре. Если есть методики.
То есть уметь написать элементарный тест — это по сути понимание что такое модульный тест в принципе. И все. До умения писать эффективные модульные тесты в реальной боевой обстановке отсюда ой как далеко. А неэффективные могут и не окупится на проекте.
Хоть сам книжки не часто читаю — но в принципе — это хороший путь разобраться во всем этом.
Я читал эту книгу, правда первое издание. Нет там никаких откровений. Вы действительно знаете книгу где написано что покрывать, а что нет? Теоретически нужно покрывать всё на 100%, а на практике нужно отталкиваться от проекта и бизнес валуе. Книги как раз-то зачастую только воду мутят, так как там теория превыше практики.
Многим людям кажется, что то, что они читают они и так знают и понимают. Мало книг, которые рассказывают что то совершенно новое. Большинство просто систематизируют знания и определения. И это не менее важно. Потому что часто кажется, что вы понимаете какую то тему, хотя на самом деле — это не так.
Вот например вы говорите, что покрывать надо на 100% или меньше отталкиваясь от проекта и бизнес валью. Я вам скажу — что это совершенно втростепенные вещи. Важно как именно вы считаете эти проценты. Что вообще включается в кавередж, а что нет. Что является изолированной бизнес логикой, а что простым маппингом или чем то еще. И дело тут не в бизнес валью, а именно в самой концепции модульных тестов. Сам по себе бизнес в приличных проектах и без модульных тестов должен быть покрыт QA процедурами (системными тестами например) — ручными или автоматизированными — вот для них ваше высказывание по настоящему актуально. Модульные тесты же служат для иных целей и там важны другие вещи.
Большинство людей в разработке начинают с практики, но набравшись практики — понимают — что нужно систематизировать свой опыт — вот тут и нужна теория. Немного скучная, кажущаяся такой знакомой (за счет встречаемых знакомых фраз), но позволяющая все еще раз переосмыслить и понять — насколько вы все поверхностно понимали.
Вот например вы говорите, что покрывать надо на 100% или меньше отталкиваясь от проекта и бизнес валью. Я вам скажу — что это совершенно втростепенные вещи. Важно как именно вы считаете эти проценты. Что вообще включается в кавередж, а что нет. Что является изолированной бизнес логикой, а что простым маппингом или чем то еще. И дело тут не в бизнес валью, а именно в самой концепции модульных тестов. Сам по себе бизнес в приличных проектах и без модульных тестов должен быть покрыт QA процедурами (системными тестами например) — ручными или автоматизированными — вот для них ваше высказывание по настоящему актуально. Модульные тесты же служат для иных целей и там важны другие вещи.
Большинство людей в разработке начинают с практики, но набравшись практики — понимают — что нужно систематизировать свой опыт — вот тут и нужна теория. Немного скучная, кажущаяся такой знакомой (за счет встречаемых знакомых фраз), но позволяющая все еще раз переосмыслить и понять — насколько вы все поверхностно понимали.
Вот, собственно сабж то о начале, из-за того что люди сразу накачиваются теорией, они боятся приступать к практике, либо слишком всё усложняют. У нас на стажёрство приходят молодые преподователи, они прекрасно знают теорию, а как доходит до практики, так караул, избыточные знания сильно мешают.
Шлифовать знания книгами, конечно нужно обязательно, но для начала хватает доки в юнит тест фреймворку.
Шлифовать знания книгами, конечно нужно обязательно, но для начала хватает доки в юнит тест фреймворку.
Хорошая книжка. Даже я с моим плохим знанием великого и могучего довольно легко смог прочитать её.
Коллеги кто читал русский перевод www.ozon.ru/context/detail/id/26230428/
поделитесь впечатлениями о качестве перевода.
поделитесь впечатлениями о качестве перевода.
Спасибо за работу! Книга на озоне доступна только в бумажной версии, а хочется электронной.
Английская версия: 1drv.ms/1ggFMuR
Вот тут много информации использовано из книги, правда я очень ужал материал до «самой сути»: habrahabr.ru/company/etnasoft/blog/169381/
Где найти коллективный перевод. Сейчас по этой (http://notabenoid.com/book/50563/) ссылке ничего не достпно
Коллективный перевод не был закончен, все забили. Вот на русском языке: yadi.sk/i/kYcsqaoymfjCZ
Sign up to leave a comment.
Перевод книги The Art of Unit Testing