Программирование, т. 8

 

это издевательство над хомяком

лучший сотрудник как мило. лучше бы вы его не мучали долбоебы

Да он сидит в клетке, а вечером его сажают а эту хуйню чтобы он побегал

 

поставьте ему колесо

я на ютубе глянул там девуля рассказывает что шар это плохо

 

 

что с ней не так?

ну, например, она пишет artefact вместо artifact

английская королева нашлась блять

 

I don't see what's wrong here mate

 

а чо не пэл?

что с ней не так?

Чужойкин на подсознательном уровне чует, что она внедрит процессы, которые упразднят отдел тестеров/автотестеров и он не за $2500 поёдут работу искать, а за $250

 

что с ней не так?

Чужойкин на подсознательном уровне чует, что она внедрит процессы, которые упразднят отдел тестеров/автотестеров и он не за $2500 поёдут работу искать, а за $250

 

тостиры останутся 

в ее надо еще постараться разрабов e2e тесты писать

был у нас опыт, когда разрабам переднего конца дали селениум и сказали ебашьте => через месяц все взвыли 

эм

а кто должен автотесты делать?

где-то заставляли разрабов их писать?

должен не должен, а идеи и предложения поступают разные

цель же не "автотесты" какие-то конкретные (юнит, е2е, интеграционные)

а цель тестировать, выявлять багги и делать это автоматом

хоть тестиры, хот автотестиры, хоть девы, хоть девопсы, хоть макаки - кого сможешь правильно организовать чтобы решалась эта проблема того и "заставляешь"

я говорю про то что в статье хороший опыт того в каких условиях что как работает

в некоторых ситуациях ты будешь разрабов "заставлять" и это будет лучшим решением

 

был у нас опыт, когда разрабам переднего конца дали селениум и сказали ебашьте => через месяц все взвыли 

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

 

 

был у нас опыт, когда разрабам переднего конца дали селениум и сказали ебашьте => через месяц все взвыли 

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

 

тут тогда надо понимать что QA это целая отрасль со своими практиками и теориями

и я не уверен что разраб компетентен в таких вещах

у нас тостиры не имеют достаточно времени на написание фреймворка и тестов по причине загрузки первичными своими задачами потому есть отдел автоматизации в котором я, который собсна эти вещи реализует и поддерживает

сейчас во многих компаниях даже ьтам куда я на собес ходил - тостир и автоматон это одно лицо - навыки и знания тестирования + кодирование этого гавна и настройка процесса но стоит он $$$

я еще не встречал компаний где нет QA по факту а QA теоретически размазано на dev 

какого хуя програмист должен базу данных создавать, для этого нужен личный бд архитектор

какого хуя програмист должен тесты писать, для этого нужны тестеры и отдел QA

какого хуя програмист должен вникать в бизнес процесы, для этого нужен прожект менеджер

какого хуя програмист должен релизы делать, для этого нужны девопсеры

а я програмист буду формочки на хтмл делать  zatrolka_tupostu

какого хуя програмист должен базу данных создавать, для этого нужен личный бд архитектор

какого хуя програмист должен тесты писать, для этого нужны тестеры и отдел QA

какого хуя програмист должен вникать в бизнес процесы, для этого нужен прожект менеджер

какого хуя програмист должен релизы делать, для этого нужны девопсеры

 

а я програмист буду формочки на хтмл делать  zatrolka_tupostu

я не скажу за всю рашку, но там где я был - почти так и есть 

Какие фреймворки, лул. уже давно все написано. В том же js есть jest, в java junit вроде. Надо просто понимать что нужно тестировать, а что нет. Например тестирование UI это тотал треш, и я бы нафиг послал всех, кто мне предложил бы разметку тестировать. Но тестировать различные функции со сложной логикой, которые перегоняют инфу из одного состояния в другое полюбому надо.

Я например писал прогу, которая выявляет различия в 2 файлах, before.json и after.json и подсвечивает, какие ключи были удалены, какие изменены... Из-за того, что json может иметь бесконечную вложенность, там была рекурсия и вот без тестирования этой штуки я бы с ума сошел потратил в разы больше времени на написание этой проги. А так у тебя есть исходный файл, пишешь окончательный файл, который должен получиться после обработки и пишешь тест вида

  const diff = gendiff(paths.before, paths.after);
  const expectedDiff = getFileContent(paths.result);
  expect(diff).toBe(expectedDiff);

Естественно у тебя тест валится, т.к. твой gendiff еще даже не написан. Ну а дальше в спокойном режиме начинаешь пилить gendiff, пока дифф исходных файлов не сойдется с написанным тобою диффом.

Ну и да, автотестеры нинужны

jest 

лул

почему то я часто наблюдаю обратную картину

девы занимаются всем, включая практически системное администрирование, и чуть ли не непосредственное общение с закачзиком (слава богу для этого всё таки всегда были аналитики/ПМы)

поднять nginx чтобы с tls чтобы работал https и/или можно было работать с госуслугами? не вопрос идем это всё ставить и разворачивать

аналитики написали хуйню в ТЗ и если по ней реализовывать то получится тыква - не вопрос идем доанализировывать и вписывать это в текущую архитектуру (системная аналитика + БА поверхностный)

дженкинс стал валиться или процесс деплоя надо переделать - невопрос

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

так что не вижу проблем

Какие фреймворки, лул. уже давно все написано. В том же js есть jest, в java junit вроде. Надо просто понимать что нужно тестировать, а что нет. Например тестирование UI это тотал треш, и я бы нафиг послал всех, кто мне предложил бы разметку тестировать. Но тестировать различные функции со сложной логикой, которые перегоняют инфу из одного состояния в другое полюбому надо.

 

Я например писал прогу, которая выявляет различия в 2 файлах, before.json и after.json и подсвечивает, какие строки были удалены, какие изменены... Из-за того, что json может иметь бесконечную вложенность, там была рекурсия и вот без тестирования этой штуки я бы с ума сошел потратил в разы больше времени на написание этой проги. А так у тебя есть исходный файл, пишешь окончательный файл, который должен получиться после обработки и пишешь тест вида

  const diff = gendiff(paths.before, paths.after);
  const expectedDiff = getFileContent(paths.result);
  expect(diff).toBe(expectedDiff);

Естественно у тебя тест валится, т.к. твой gendiff еще даже не написан. Ну а дальше в спокойном режиме начинаешь пилить gendiff, пока результат исходного файла не сойдется с результатом файла после обработки.

 

Ну и да, автотестеры нинужны

я думаю под собственными фреймворками подразумевается что у тебя есть специфика проекта которая завязана на бизнес объекты, конкретные сущности, и прочее

когда фреймворки общие не очень подходят, либо используют их под капотом а наверх показывают более высокоуровневое написание тестов 

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

В тестировании того что при определенных пропсах у тебя показываются нужные элементы не меньше смысла чем в тестировании бизнес логики

Хз, если уж в этом есть какой-то смысл, то пусть этой фигней занимаются тестировщики. А так я уже слышал истории, когда чуваки меняют разметку, тест (снапшот) начинается валится и они просто говорят "бро теперь вот эта разметка правильная"   
А бизнес логика обычно не меняется 10 раз на дню.

 

я думаю под собственными фреймворками подразумевается что у тебя есть специфика проекта которая завязана на бизнес объекты, конкретные сущности, и прочее

когда фреймворки общие не очень подходят, либо используют их под капотом а наверх показывают более высокоуровневое написание тестов 

this

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

на западе тестировщики потихоньку отмирают.

поэтому основные теоретики и практики QA с запада      

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

и вот эта пизда к нам сегодня вышла на одно из ключевых направлений

https://habr.com/company/alfa/blog/352312/

Лол, она у нас в саратове на конференции будет в субботу выступать

Ну так пойди к ней на выступление и задай вопрос почему она не на кухне

Ебать, она на дауна похожа