#статья дня
Глупо считать, что сложные системы это привилегия айти, пусть даже айти зачастую пронизывает их с ног до головы. Хотя, конечно, стоит признать, что даже кажущиеся простыми системы на самом деле далеко не такие (на иллюстрации — система уведомлений в Slack).
Поэтому ровно так же глупо считать, что отладка сложных систем и разбор инцидентов должны происходить только по айтишным принципам и правилам. Например, тот же самый «подход «пяти почему?», широко разрекламированный книгой и движением «Бережливый стартап», слишком часто применяется чтобы найти виноватого, но никак не чтобы улучшить систему.
Сегодняшняя статья имеет простое и понятное название: «How Complex Systems Fail», имеется перевод на русский: «Как ломаются сложные системы». Автор — доктор Ричард Кук. В смысле медицины доктор.
В чём суть? Всё просто: опасность – неотъемлемый атрибут сложных систем. На этом можно было бы и закончить, но там ещё 17 пунктов. Кому-то они помогут расслабиться, очень надеюсь.
Забавно, что некоторые из пунктов отлично вписываются в рефакторинг. Например:
10. Все действия специалистов – авантюры
14. Изменения создают новые виды сбоев
18. Работа без сбоев требует опыта работы со сбоями
Прописные истины? Возможно. Но их стоило собрать в одном месте. И собрали — аж в 1998 году.
В общем, всем рекомендую, котаны.
#system #testing
Глупо считать, что сложные системы это привилегия айти, пусть даже айти зачастую пронизывает их с ног до головы. Хотя, конечно, стоит признать, что даже кажущиеся простыми системы на самом деле далеко не такие (на иллюстрации — система уведомлений в Slack).
Поэтому ровно так же глупо считать, что отладка сложных систем и разбор инцидентов должны происходить только по айтишным принципам и правилам. Например, тот же самый «подход «пяти почему?», широко разрекламированный книгой и движением «Бережливый стартап», слишком часто применяется чтобы найти виноватого, но никак не чтобы улучшить систему.
Сегодняшняя статья имеет простое и понятное название: «How Complex Systems Fail», имеется перевод на русский: «Как ломаются сложные системы». Автор — доктор Ричард Кук. В смысле медицины доктор.
В чём суть? Всё просто: опасность – неотъемлемый атрибут сложных систем. На этом можно было бы и закончить, но там ещё 17 пунктов. Кому-то они помогут расслабиться, очень надеюсь.
Забавно, что некоторые из пунктов отлично вписываются в рефакторинг. Например:
10. Все действия специалистов – авантюры
14. Изменения создают новые виды сбоев
18. Работа без сбоев требует опыта работы со сбоями
Прописные истины? Возможно. Но их стоило собрать в одном месте. И собрали — аж в 1998 году.
В общем, всем рекомендую, котаны.
#system #testing
👍17
#статья дня
Даже не одна статья, а целая серия из пяти. Автор — Артём Сапегин.
И серия статей эта — о тестировании в React. От лучших практик и ответа на вопрос, зачем тестировать вообще (кстати, зачем?), до описания работы с Jest, Enzyme, React Testing Library (ныне уже стандартный способ), Cypress и Playwright.
Ссылка на первую статью цикла: https://sapegin.me/blog/react-testing-1-best-practices/
Надо отметить, что начало цикла — это 2020 год (камень в огород Артёма: это было весьма сложно вычислить, нужны даты), но каждая из статей была не раз обновлена.
Ну и с тех пор Enzyme практически перестали использовать, во всяком случае в моём кругу. Если у вас иная информация — поделитесь.
В любом случае, труд масштабный, монументальный даже, и стоит ознакомления.
#react #testing
Даже не одна статья, а целая серия из пяти. Автор — Артём Сапегин.
И серия статей эта — о тестировании в React. От лучших практик и ответа на вопрос, зачем тестировать вообще (кстати, зачем?), до описания работы с Jest, Enzyme, React Testing Library (ныне уже стандартный способ), Cypress и Playwright.
Ссылка на первую статью цикла: https://sapegin.me/blog/react-testing-1-best-practices/
Надо отметить, что начало цикла — это 2020 год (камень в огород Артёма: это было весьма сложно вычислить, нужны даты), но каждая из статей была не раз обновлена.
Ну и с тех пор Enzyme практически перестали использовать, во всяком случае в моём кругу. Если у вас иная информация — поделитесь.
В любом случае, труд масштабный, монументальный даже, и стоит ознакомления.
#react #testing
👍20
#заметка дня
Рубрика "Вы не спрашивали, но я всё равно отвечу!"
На самом деле, разговор произошёл в Твиттере, и я посчитал разумным, вынести его сюда.
Итак, вопрос:
Что бы убедиться: использование testid в end-2-end тестах для выборки элементов это анти-паттерн, верно? Следует тестировать с точки зрения пользователя: искать кнопку с неким текстом, например.
Знаете ли вы статьи или доклады, которые подкрепляют эту точку зрения?
Отвечаю:
Это не то чтобы антипаттерн, это просто бестолковое использование ресурсов, потому и продвигается как антипаттерн.
1. Надо тестировать то, что видит юзер
2. Если что-то не видит, значит, всё плохо
3. Если там иконка или нужен результат — искать надо по a11y атрибутам.
Сразу поясню за "бестолковость".
Когда ты что-то тестируешь, тесты становятся твоей документацией. Значит, в тестах закрепляется текущее поведение проекта. Даже строки не стоит импортировать (если ты только не тестируешь систему перевода).
А это значит, если кто-то случайно сломает систему перевода или неправильно переведёт строку без информирования остальных — тесты упадут и это правильно.
Дальше, решая проблему через ARIA-атрибуты, ты заодно решаешь вопрос доступности. Бесплатно. Поэтому data-testid и названы бестолковым использованием ресурсов.
Это же, кстати, касается систем трекинга вроде Datadog RUM.
Смысл фронтенда в том, чтобы пользователь мог с продуктом взаимодействовать. Для этого необходима визуальная и когнитивная поддержка. Кнопка может быть и видна, но на кнопке — упс — может не быть текста. Или она будет цвета фона (потому скриншот-тесты ещё не вымерли).
Подобный подход к тестировани применяется как в E2E, так и в юнит- и интеграционном тестировании. Вот, например, поясняющая статья от Testing Library, которая нынче стандарт де-факто для тестирования в вебе.
Тестируйте, котаны!
#web #testing #e2e
Рубрика "Вы не спрашивали, но я всё равно отвечу!"
На самом деле, разговор произошёл в Твиттере, и я посчитал разумным, вынести его сюда.
Итак, вопрос:
Что бы убедиться: использование testid в end-2-end тестах для выборки элементов это анти-паттерн, верно? Следует тестировать с точки зрения пользователя: искать кнопку с неким текстом, например.
Знаете ли вы статьи или доклады, которые подкрепляют эту точку зрения?
Отвечаю:
Это не то чтобы антипаттерн, это просто бестолковое использование ресурсов, потому и продвигается как антипаттерн.
1. Надо тестировать то, что видит юзер
2. Если что-то не видит, значит, всё плохо
3. Если там иконка или нужен результат — искать надо по a11y атрибутам.
Сразу поясню за "бестолковость".
Когда ты что-то тестируешь, тесты становятся твоей документацией. Значит, в тестах закрепляется текущее поведение проекта. Даже строки не стоит импортировать (если ты только не тестируешь систему перевода).
А это значит, если кто-то случайно сломает систему перевода или неправильно переведёт строку без информирования остальных — тесты упадут и это правильно.
Дальше, решая проблему через ARIA-атрибуты, ты заодно решаешь вопрос доступности. Бесплатно. Поэтому data-testid и названы бестолковым использованием ресурсов.
Это же, кстати, касается систем трекинга вроде Datadog RUM.
Смысл фронтенда в том, чтобы пользователь мог с продуктом взаимодействовать. Для этого необходима визуальная и когнитивная поддержка. Кнопка может быть и видна, но на кнопке — упс — может не быть текста. Или она будет цвета фона (потому скриншот-тесты ещё не вымерли).
Подобный подход к тестировани применяется как в E2E, так и в юнит- и интеграционном тестировании. Вот, например, поясняющая статья от Testing Library, которая нынче стандарт де-факто для тестирования в вебе.
Тестируйте, котаны!
#web #testing #e2e
Testing-Library
React Testing Library | Testing Library
React Testing Library builds on top of DOM Testing Library by adding
👍16❤1
#статья дня
Глупо считать, что сложные системы это привилегия айти, пусть даже айти зачастую пронизывает их с ног до головы. Хотя, конечно, стоит признать, что даже кажущиеся простыми системы на самом деле далеко не такие (на иллюстрации — система уведомлений в Slack).
Поэтому ровно так же глупо считать, что отладка сложных систем и разбор инцидентов должны происходить только по айтишным принципам и правилам. Например, тот же самый «подход «пяти почему?», широко разрекламированный книгой и движением «Бережливый стартап», слишком часто применяется чтобы найти виноватого, но никак не чтобы улучшить систему.
Сегодняшняя статья имеет простое и понятное название: «How Complex Systems Fail», имеется перевод на русский: «Как ломаются сложные системы». Автор — доктор Ричард Кук. В смысле медицины доктор.
В чём суть? Всё просто: опасность – неотъемлемый атрибут сложных систем. На этом можно было бы и закончить, но там ещё 17 пунктов. Кому-то они помогут расслабиться, очень надеюсь.
Забавно, что некоторые из пунктов отлично вписываются в рефакторинг. Например:
10. Все действия специалистов – авантюры
14. Изменения создают новые виды сбоев
18. Работа без сбоев требует опыта работы со сбоями
Прописные истины? Возможно. Но их стоило собрать в одном месте. И собрали — аж в 1998 году.
В общем, всем рекомендую, котаны.
#system #testing #бородач
Глупо считать, что сложные системы это привилегия айти, пусть даже айти зачастую пронизывает их с ног до головы. Хотя, конечно, стоит признать, что даже кажущиеся простыми системы на самом деле далеко не такие (на иллюстрации — система уведомлений в Slack).
Поэтому ровно так же глупо считать, что отладка сложных систем и разбор инцидентов должны происходить только по айтишным принципам и правилам. Например, тот же самый «подход «пяти почему?», широко разрекламированный книгой и движением «Бережливый стартап», слишком часто применяется чтобы найти виноватого, но никак не чтобы улучшить систему.
Сегодняшняя статья имеет простое и понятное название: «How Complex Systems Fail», имеется перевод на русский: «Как ломаются сложные системы». Автор — доктор Ричард Кук. В смысле медицины доктор.
В чём суть? Всё просто: опасность – неотъемлемый атрибут сложных систем. На этом можно было бы и закончить, но там ещё 17 пунктов. Кому-то они помогут расслабиться, очень надеюсь.
Забавно, что некоторые из пунктов отлично вписываются в рефакторинг. Например:
10. Все действия специалистов – авантюры
14. Изменения создают новые виды сбоев
18. Работа без сбоев требует опыта работы со сбоями
Прописные истины? Возможно. Но их стоило собрать в одном месте. И собрали — аж в 1998 году.
В общем, всем рекомендую, котаны.
#system #testing #бородач
👍14🤩1
#инструмент дня
Четыре (охереть) года назад я писал большую серию статей на тему того, как же тестировать WebKit aka Safari на Windows и Linux. Вот, можете почитать: https://t.me/htmlshit/705
Дайте знать, если пора эту серию статей обновить!
И тогда мы остановились на том, что можно просто использовать... Browserstack!
Но не все могут себе позволить даже 150 долларов в год за фриланс-план… или всё же есть выход?
Выход правда есть!
Browserstack активно поддерживает open-source проекты и даёт бесплатные лицензии на год!
Если у вас есть такой — смело топайте на https://www.browserstack.com/open-source и вбивайте там ссылку на репозиторий.
Главное — чтобы была подходящая лицензия. Полного списка я не нашёл, но уверен, что GPL, BSD и MIT точно включены. Я же указал Creative Commons Attribution 4.0 International.
Ах да, что же у меня за проект такой опенсорс? Да просто сайт этого канала: https://github.com/HTMLShit/htmlshit.site
Он в анабиозе сейчас, но работу над ним можно и восстановить. Да и пульт мой я ещё подумываю открыть.
Так вот, доступ обновляется каждый год пока репозиторий доступен! У меня, выходит, уже 4 года.
После прохождения ручной модерации, мне пришло письмо. Я получил годовые планы тестирования браузера и мобильных с весьма вкусными условиями.
Короче, если вы ещё не начали свой проект – чего вы ждёте вообще?
#browserstack #testing
Четыре (охереть) года назад я писал большую серию статей на тему того, как же тестировать WebKit aka Safari на Windows и Linux. Вот, можете почитать: https://t.me/htmlshit/705
Дайте знать, если пора эту серию статей обновить!
И тогда мы остановились на том, что можно просто использовать... Browserstack!
Но не все могут себе позволить даже 150 долларов в год за фриланс-план… или всё же есть выход?
Выход правда есть!
Browserstack активно поддерживает open-source проекты и даёт бесплатные лицензии на год!
Если у вас есть такой — смело топайте на https://www.browserstack.com/open-source и вбивайте там ссылку на репозиторий.
Главное — чтобы была подходящая лицензия. Полного списка я не нашёл, но уверен, что GPL, BSD и MIT точно включены. Я же указал Creative Commons Attribution 4.0 International.
Ах да, что же у меня за проект такой опенсорс? Да просто сайт этого канала: https://github.com/HTMLShit/htmlshit.site
Он в анабиозе сейчас, но работу над ним можно и восстановить. Да и пульт мой я ещё подумываю открыть.
Так вот, доступ обновляется каждый год пока репозиторий доступен! У меня, выходит, уже 4 года.
После прохождения ручной модерации, мне пришло письмо. Я получил годовые планы тестирования браузера и мобильных с весьма вкусными условиями.
Короче, если вы ещё не начали свой проект – чего вы ждёте вообще?
#browserstack #testing
1👍15
#заметка дня
Рубрика "Вы не спрашивали, но я всё равно отвечу!"
На самом деле, разговор произошёл в Твиттере, и я посчитал разумным, вынести его сюда.
Итак, вопрос:
Что бы убедиться: использование testid в end-2-end тестах для выборки элементов это анти-паттерн, верно? Следует тестировать с точки зрения пользователя: искать кнопку с неким текстом, например.
Знаете ли вы статьи или доклады, которые подкрепляют эту точку зрения?
Отвечаю:
Это не то чтобы антипаттерн, это просто бестолковое использование ресурсов, потому и продвигается как антипаттерн.
1. Надо тестировать то, что видит юзер
2. Если что-то не видит, значит, всё плохо
3. Если там иконка или нужен результат — искать надо по a11y атрибутам.
Сразу поясню за "бестолковость".
Когда ты что-то тестируешь, тесты становятся твоей документацией. Значит, в тестах закрепляется текущее поведение проекта. Даже строки не стоит импортировать (если ты только не тестируешь систему перевода).
А это значит, если кто-то случайно сломает систему перевода или неправильно переведёт строку без информирования остальных — тесты упадут и это правильно.
Дальше, решая проблему через ARIA-атрибуты, ты заодно решаешь вопрос доступности. Бесплатно. Поэтому data-testid и названы бестолковым использованием ресурсов.
Это же, кстати, касается систем трекинга вроде Datadog RUM.
Смысл фронтенда в том, чтобы пользователь мог с продуктом взаимодействовать. Для этого необходима визуальная и когнитивная поддержка. Кнопка может быть и видна, но на кнопке — упс — может не быть текста. Или она будет цвета фона (потому скриншот-тесты ещё не вымерли).
Подобный подход к тестировани применяется как в E2E, так и в юнит- и интеграционном тестировании. Вот, например, поясняющая статья от Testing Library, которая нынче стандарт де-факто для тестирования в вебе.
Тестируйте, котаны!
#web #testing #e2e #бородач
Рубрика "Вы не спрашивали, но я всё равно отвечу!"
На самом деле, разговор произошёл в Твиттере, и я посчитал разумным, вынести его сюда.
Итак, вопрос:
Что бы убедиться: использование testid в end-2-end тестах для выборки элементов это анти-паттерн, верно? Следует тестировать с точки зрения пользователя: искать кнопку с неким текстом, например.
Знаете ли вы статьи или доклады, которые подкрепляют эту точку зрения?
Отвечаю:
Это не то чтобы антипаттерн, это просто бестолковое использование ресурсов, потому и продвигается как антипаттерн.
1. Надо тестировать то, что видит юзер
2. Если что-то не видит, значит, всё плохо
3. Если там иконка или нужен результат — искать надо по a11y атрибутам.
Сразу поясню за "бестолковость".
Когда ты что-то тестируешь, тесты становятся твоей документацией. Значит, в тестах закрепляется текущее поведение проекта. Даже строки не стоит импортировать (если ты только не тестируешь систему перевода).
А это значит, если кто-то случайно сломает систему перевода или неправильно переведёт строку без информирования остальных — тесты упадут и это правильно.
Дальше, решая проблему через ARIA-атрибуты, ты заодно решаешь вопрос доступности. Бесплатно. Поэтому data-testid и названы бестолковым использованием ресурсов.
Это же, кстати, касается систем трекинга вроде Datadog RUM.
Смысл фронтенда в том, чтобы пользователь мог с продуктом взаимодействовать. Для этого необходима визуальная и когнитивная поддержка. Кнопка может быть и видна, но на кнопке — упс — может не быть текста. Или она будет цвета фона (потому скриншот-тесты ещё не вымерли).
Подобный подход к тестировани применяется как в E2E, так и в юнит- и интеграционном тестировании. Вот, например, поясняющая статья от Testing Library, которая нынче стандарт де-факто для тестирования в вебе.
Тестируйте, котаны!
#web #testing #e2e #бородач
Testing-Library
React Testing Library | Testing Library
React Testing Library builds on top of DOM Testing Library by adding
3👍7❤4