Но при всех очевидных плюсах закрался один существенный недостаток: минимальная версия начинается с iOS 17, что делает использование SwiftData непозволительно дорогим для крупных приложений, но почти идеальным решением для работы над различными pet-проектами.
Все же лучше иметь чем не иметь, а крупные приложения если не вымрут рано или поздно дойдут до нужной версии (вопрос про базу пользователей ток)
Про снапшот- и скриншот-тесты заведомо известно, что они упадут при любом изменении кода компонента.
Придумываем ситуацию где на гавнокодили сделал долгие операции в компоненте, но написали все тесты, затем рефакторинг (да даже переход с js\flow\ts на js\flow\ts) и после тестов понятно изминился результат после рефакторинга или нет
Вам рассказать, сколько всего можно сделать и показать в вебе без единой строчки текста, или вы таки воображение сами включите?
токсично, но я ориентировался на ваш пример где использовался button и div
Ничего не понял. Ну вот вы поменяли что-то. Тесты упали. Вы пересоздали снапшоты и счастливо пошагали дальше. Что конкретно тут "помогает" и чему оно помогает?
Упал тест — заскипал, пошел, дальше. Я вас верно услышал ?
говнокод и говноархитектура
"Для этого существует code review" — это ведь то же бы могло решить это проблему но видимо не решает
Я где-то говорил "тесты писать не нужно"? Ссылочку дадите?
"Любой тест, про который заранее известно, что он упадёт при изменении кода" — все тесты пишутся чтобы изминением кода не затронуть лишние части приложения. Или я вас не так понял? и вы не имели ввиду "любой" тест
Всмысле нет а тогда что вы показываете пользователю и что там проверяете ?
Изменился код — упали тесты. Не изменился код — не упали тесты. Зачем оно?
Помогает при малейшем рефакторинге (при быстром деливвиринге фитч всегда падает планка хорошего кода оптимизации и т.д.)
У вас много случаев, когда вы считали, что ничего не должно поменяться, а оно менялось?
ни кто не убирает человеческий фактор что кто то может что то не заметил
или вы предпалагает е что все 100% пишут всегда лаконичный код который лишнего не цепляет и ничего не забывает сделать (а как же тип программирование через тестирование когда в начале пишут тест а потом пишут интерфейс, функцию коотрая этот тест проходит)
Если много — тут повод много думать об архитектуре приложения, а не тесты дальше фигачить.
везде есть есть тонкости но говориьт что тесты писать не нужно это перебор
3. Вывод дочерних контекстов с отрицательными z-index
4. Вывод дочерних блочных элементов в нормальном потоке (только фоны)
5. Вывод дочерних float элементов
6. Вывод контента элементов в нормальном потоке: инлайновые и инлайново-блочные потомки, инлайновый контент внутри блочных потомков, включая строки текста *
7. Вывод дочерних контекстов с нулевыми и auto z-index **
8. Вывод дочерних контекстов с положительными z-index
* в порядке обхода дерева depth-first
** для контекстов с z-index: auto все дочерние контексты считать потомками текущего контекста, то есть «вытаскивать» их наверх на текущий уровень
Сколько искал не нашел первых двух, автор поправь или направь меня на эти пункты ))
Можно примерно проиллюстрировать данную схему следующей картинкой:
Думаю можно было бы вставить html разметку
Хотелось больше узнать про отрисовку элементов с указанным opacity свойством меньше единицы.
Спасибо за статью!
Основание компании все же люди, если слишком сильно шатать основание (низко оплачиваемость, трудные условия работы и т.д.) тогда и управлять будет не кем.Да может скажете что 70 из 1000 это не 10% но это те люди которые знаю своё дело и если что то не так пойдёт они быстрее всех найдут косяк, чем новый работник. Хотя для большого бизнеса люди становятся сырьём и лишь только совесть не даёт нам этого понять.
Спасибо - интересная статья.
Все же лучше иметь чем не иметь, а крупные приложения если не вымрут рано или поздно дойдут до нужной версии (вопрос про базу пользователей ток)
Статья (врятли ее так можно назвать) перевод которого не следовало бы делать
Заголовок и заключение , аля смотри как накалякать.
Придумываем ситуацию где на гавнокодили сделал долгие операции в компоненте, но написали все тесты, затем рефакторинг (да даже переход с js\flow\ts на js\flow\ts) и после тестов понятно изминился результат после рефакторинга или нет
токсично, но я ориентировался на ваш пример где использовался button и div
Упал тест — заскипал, пошел, дальше. Я вас верно услышал ?
"Для этого существует code review" — это ведь то же бы могло решить это проблему но видимо не решает
Всмысле нет а тогда что вы показываете пользователю и что там проверяете ?
Помогает при малейшем рефакторинге (при быстром деливвиринге фитч всегда падает планка хорошего кода оптимизации и т.д.)
ни кто не убирает человеческий фактор что кто то может что то не заметил
или вы предпалагает е что все 100% пишут всегда лаконичный код который лишнего не цепляет и ничего не забывает сделать (а как же тип программирование через тестирование когда в начале пишут тест а потом пишут интерфейс, функцию коотрая этот тест проходит)
везде есть есть тонкости но говориьт что тесты писать не нужно это перебор
Ну так react testing labriry есть возможность искать не по элементу а по тексту в элементе
getByText
а то что верстка съехала да тестируем скриншот тестами
Сколько искал не нашел первых двух, автор поправь или направь меня на эти пункты ))
Думаю можно было бы вставить html разметку
Хотелось больше узнать про отрисовку элементов с указанным opacity свойством меньше единицы.
Спасибо за статью!
Основание компании все же люди, если слишком сильно шатать основание (низко оплачиваемость, трудные условия работы и т.д.) тогда и управлять будет не кем.Да может скажете что 70 из 1000 это не 10% но это те люди которые знаю своё дело и если что то не так пойдёт они быстрее всех найдут косяк, чем новый работник. Хотя для большого бизнеса люди становятся сырьём и лишь только совесть не даёт нам этого понять.