везде где вижу "удобное" форматирование log message исправляю на "шаблон отдельно, значения отдельно".
Изначально, мотивация была именно такая - зачем каждый раз перед вызовом делать то, что с какой-то вероятностью не потребуется. Но сейчас кто смотрит на эти копейки эффективности.
В какой-то момент, эта мотивация дополнилась тем, что протоколирование - это не всегда "строки текста". Сколько лет уже продвигается ELK и прочие технологии сбора/анализа/итд? Форматирование в человекочитаемую строку может быть вообще не потребуется, или это сделают где-то там, в каком-нибудь ELK, причем не только для debug, но вообще для всего. Причем, сегодня про "такой поворот" может быть даже никто и не думает, а через год, вместо того, что бы в условно одном месте заменить log writer, будут устраивать ревизию всему коду.
Работать утилита должна на любом компьютере с ОС Windows выше Windows 7 или Windows Server 2008 без установки каких-либо фреймворков и Runtime Environment. Должен быть установлен только какой-то из продуктов Oracle, включающий OCI-библиотеку.
Кажется, сейчас разобраться с каким-либо популярным в текущий момент "упаковщиком всего нужного в один бинарник" для "вашего любимого инструмента разработки" проще и выгоднее (по затрате усилий), чем писать клиентские приложения для OracleDB на C/C++ И не могу промолчать уходя немного в оффтопик: довелось длительное время (лет 10, наверное) внедрять и сопровождать продукт, у которого в качестве базы данных Oracle DB, и на фоне вот того опыта, слова "должен быть какой-то из продуктов Oracle, включающий OCI", у меня вызывают нервный смех. Прекратил всего этого касаться я когда еще не перешли целиком на 12c, а только присматривались. У версий 10 и 11, с вот этим все очень-очень-очень всё непросто, и может быть множество разных неожиданных фокусов даже если у сервера базы и клиента разные patch level. Другими словами, я не верю, что в реальной жизни можно полностью исключить какую-либо установку чего-либо из продуктов Oracle на компьютер с клиентским приложением. В тоже время, могу легко представить, что есть четки процедуры развертывания/обновления клиентских мест, но тогда известен набор "что должно быть точно", и опять-же, гораздо эффективнее, расширить этот набор, добавив требуемые библиотеки, а утилиты разрабатывать используя удобные инструменты.
Я не хотел сделать супер-пупер инструмент, я хочу его сделать.
Обычно люди делают инструмент для решения какой-то задачи. Какие задачи с использованием вашего языка будет решать лучше (проще, удобнее, приятнее, итд), чем с использованием любого другого уже существующего языка?
Я вообще не вижу никаких проблем.
Человек написал статью на популярном ресурсе — для меня это означает, что попросил обратную связь. Я эту обратную связь ему даю, да и вы, по сути делаете то же самое.
Это очень ценный опыт
— «опыт, это то, что ты получаешь, вместо того, что хотел». Применяя к текущей ситуации — хотел сделать супер-пупер инструмент, а получил опыт.
Опыт на собственных ошибках ценнее опыта чужого.
— кроме тех случаев, когда собственная ошибка приводит к гибели.
Применяя к текущей ситуации — «гибели» заметного количества времени и сил, вложенных в такой проект.
Мой вывод на основе той информации что я вижу простой: свой проект в текущем виде остановить, найти наиболее близкий по вкусу живой проект и прикладывать усилия туда.
Если цель проекта в первую очередь «получить опыт», то участие в живом проекте, позволит достингуть этой цели меньшими затратами, с высокой вероятностью опыт будет «более полезный».
В качестве бонуса будет то самое необязательное «проект в проде», откуда можно будет зачерпнуть очередную порцию энтузиазма на следующий проект.
Продолжение пиления своего велосипеда, я оцениваю, как тупиковый сценарий — начальных запал иссякнет, в обмен на это будет кучка разрозненных знаний вида «нахватался по верхам» и выгорание.
делать свой язык программирования != делать свои проекты
Оглянитесь вокруг — есть много, нет МНОГО языков. Популярные, можно пересчитать по пальцам на руках. За каждым из них — большая история, и если переводить в человеко-часы, вообще сложно оценить.
Посмотрите молодые (5-6 лет) растущие языки, с чего они начинались, и на каких усилиях они растут. Всё это, если не прямо сейчас, то очень скоро начнет «давить» не энтузиазм начинателя нового языка.
Я бы сказал, что в общем случае — нет. Можно сделать 100500 велосипедов, так ничему и не научиться. А в тяжелом случае, еще разбить себе лоб, в ходе испытаний очередной кривой самоделки.
Двигатель прогресса — человек, который разобрался в теме лучше/глубже, чем все, кто брался за эту тему до него. На мой взгляд, не принципиально, он смог это только за счет целеустремленности или посмотрел на задачу с нового ракурса. Важно, что сделал лучше.
Главное, чтобы был напарник для код-ревью (желательно более опытный), чтобы не застрять в собственном информационном пузыре
Допустим. Как найти опытного напарника на ревью реализации нового языка?
ой, подождите… Если отправить пулл-реквест в уже существующий проект, его обязательно кто-то посмотрит, и скорее всего, это будет более опытный разработчик?
Простите, но я последние лет 10-15 видимо слишком много наблюдаю вокруг людей, которым что-то хочется, но они не понимают чего именно, и делают то, что получается. А из того малого числа, которые понимают что именно им хочется, львиная доля не понимает, как наиболее эффективно достигать желаемого.
Наверное, это у меня такая проф.деформация, и слишком много по жизни приходилось копаться в чужом коде, который вроде работает в каких-то частных случаях, но выглядит отвратительно, что если через год-два-три изменяются требования, то возникает вопрос — нам действительно будет дешевле модифицировать «вот это»?
затрагивает большое число тем CS
— это основная проблема для новичка. Это как «можно сделать хорошо, быстро, недорого — выбирайте любые два». В случае новичка — будет чудо, если у него получится хотя бы одному из трех требований удовлетворить. Поэтому, я убежден (никому не навязываю, но считаю важным озвучить) — если основная цель «научиться. разобраться, понять» — нужно взять уже что-то хоть в каком-то виде цельное-живое-рабочее, брать по «одной теме CS», и модифицировать это самое живое рабочее, разбираясь, почему границы между бекенд/фронтенд в этом случае провели именно так, почему лексер именно так написан, почему грамматика такая, когда их вон сколько разных?
При таком подходе, шансы того, что хоть в какой-то теме получится разобраться гораздо выше, чем если перед глазами десяток тем, и любой шаг вправо/влево, ломает весь мир.
Не думаю, что это так работает. По крайней мере, не для всех. Именно такие минусы и убивают энтузиазм.
А как это работает? Если человеку хочется писать код, хочется, что бы код запускался — ему не нужен Хабр, ему вообще никто не нужен.
Как только возникает мысль кому-то рассказать — это один из способов получить какой-то взгляд со стороны. Вот такой взгляд со стороны получен.
Но я не понимаю вашего вопроса «зачем?». Ровно как и не понимаю зачем вообще создавать новый язык в 2021 году.
Язык — это инструмент. Зачем еще один инструмент, ни из статьи ни из ответов не понятно.
Поэтому простой короткий вывод — не зачем. И простая короткая рекомендация — прежде чем делать что-то совсем новое, попробуйте разобраться с чем-то, что уже используют люди. У всего есть недостатки, и того, что open source, есть возможность недостатки исправить. Это гораздо более достижимая цель, которая даст гораздо больше общей пользы, чем убить кучу сил и времени на новое, никому ненужное произведение.
Начинать новый проект языка — лучший способ просрать (простите) весь энтузиазм. Что может быть хорошего, когда человек выкидывает свой самый ценный ресурс — время?
Лично я минусовал по двум причинам:
— в надежде, что человек задумается «а почему минусуют, что не так?»
— однообразные комментарии, похожие на копипасту слов из статьи и соседних своих же комментариев.
«Критикуя предлагай»: Гораздо лучше найти наиболее близкий по духу/идее/итд проект и помогать его развитию. И с точки зрения достижения результата (этим будет пользоваться кто-то еще), и с точки зрения получения опыта, и с точки зрения разобраться, и с еще кучи других аспектов, вплоть, до улучшения мира в целом.
Весомую часть проблемы автор поста сформулировал в начале — описания товаров плохие. У продавца нет стимула улучшать описание. С факта продажи зарабатывает продавец (платформа, дистрибьютор, производитель). И если вся эта цепочка не может обеспечить «хорошую витрину», какие шансы, что у активные покупатели, и заинтересованная платформа (поисковый движок) сможет?
Единственный комментарий, который хоть куда-то может привести. Но формулировка «улучшать конкуренцию», кажется совсем не технологическая.
У меня вопрос звучит иначе — прежде чем что-то улучшать, нужна цель и метрики.
Проблема в том, что магазинам не нужно «улучшать поиск».
Как в известном выражении: «людям не нужны дрели, им нужно картину на стену повесить»
Есть монстры, тот же Маркет, Озон, Вайлдберис — у них свои большие команды разработки. У следующих, крупных — видимо тоже.
Есть «серединка» — они, вероятно, аутсорсят всякое у крупных студий/команд.
И есть небольшие — они, кажется, или не парятся, используют то, что дает платформа (битрикс, шопифай, магенту), или находят фрилансеров (небольшие команды).
Как бы то ни было — в рамках онлайн магазина есть масса вопросов «что сделать лучше», какое место в этой массе занимает именно «сделать лучше поиск»?
Что бы ответить на этот вопрос, нужно четко понимать: сколько «денег» даст улучшение поиска, и сколько денег стоит это улучшение, и как эти выгоды-затраты соотносятся с другими вопросами.
Рекламный пост — не проблема, проблема в качестве рекламы.
Когда, скажем, интегратор/монтажник, на основе своего опыта рекламирует систему производителя-партнера, интересно читать даже если не рассказывают о минусах/сложностях.
А когда просто накидали красивых слов, которые вроде бы похожи на правду — фигня получается, а не реклама
Конечно, это статья не для меня. Но я написал комментарий потому, что считаю, что начальный тезис «дали тестировать непонятно что, что делать — вот 100500 вариантов» — вредна при тестировании.
Если возникает вопрос что проверять, ответ на этот вопрос нужно искать не в рамках тестирования. И это очень важно понимать особенно новичку в тестировании.
Не вижу никакой проблемы, если тестировщик обратится к аналитику, продакту, и уточнит — «вот тут что должно быть?».
Если продолжить тезис про поля ввода из соседней ветви:
— все поля ввода одинаковые, текст, максимальный размер введенного?
Если, например есть, поля ввода с валидаторами, где-то за рамками тестов ведь должно быть записано «в этом поле разрешены только цифры», «в этом поле — месяц, 1-2 цифры»? Если такое не записано, как тестировщик может написать тест на ввод месяца в текстовое поле? Он должен проверять все варианты? Какие из вариантов считать правильными, какие нет? «январь», «янв», «01», «1», какие?
Могу только развести руками и пожелать вам, когда вы будите тимлидом (если еще не стали) — старайтесь более точно формулировать свои мысли.
К большому сожалению, ситуация когда приходится пользоваться не очень качественным продуктом (сторонняя библиотека — продукт, которым вы пользовались, наличие документации, её актуальность — один из критериев качества) распространена шире, чем хотелось бы. На мой взгляд выход из этой ситуации следовать трем пунктам
* определить для себя нижний уровень качества
* всегда выбирать более качественный продукт в рамках бюджета
* если по итогам всех выборов и оценок не удается достичь минимального уровня, либо не браться за задачу, либо пересматривать бюджет, либо пересматривать задачу.
По сути это ровно то же самое/, что я пытаюсь донести в соседних комментариях — без четкого понимания «что должно быть в результате», не вижу вариантов хорошо решить задачу тестирования.
будьте добры, покажите примеры статей, где пишут, что в scrum/kanban/agile не предполагается документация. Боюсь, вы путаете с «не предполагается отдельной фазы проектирования всего продукта, до начала работ».
Если взять семейство agile-методик, у которых ключевой момент — короткие итерации, то насколько короткой итерацию не делай (хоть вообще один день), всегда есть «заказчик», «исполнитель», «ожидаемый результат». Ожидаемый к концу итерации. Записывают его на доске, в issue или просто встретившись утром у кулера обмениваются парой-тройкой фраз, если исполнителю не будут понятно, что от него ожидают — скорее всего, он сделает какую-то фигню не то, что ожидают.
Мне, как заказчику, нужен результат, за фигню я не готов платить.
Я, как исполнитель, ровно в той-же степени хочу выдать результат, если, конечно, мне важно, что бы за мою работу заплатили.
Очень странно рассчитывать, что за фигню будут платить. Еще более странно платить за фигню, хотя окружающая действительность как бы говорит, что так поступают чаще, чем хотелось бы. Успокаивает только то, что ожидаемый результат платят значительно больше (на порядки?) чем за фигню.
нет, у меня почти никогда не было ТЗ. Но первое, что я в этом случае делал — писал ТЗ, а не пытался «что-то сделать, похожее на деятельность». Причина этому простая — если мне ставят задачу недостаточно четко, для её выполнения, с высокой вероятностью, результат моей работы не будет принят с первого раза (а скорее всего со второго, третьего итд), и с еще более высокой вероятностью, суммарные затраты на переделки будут выше, чем сначала «договориться на берегу» — написать ТЗ, хоть в каком-то виде, по которому можно будет принять работу, а потом уже приступать к работе.
Это настолько общий принцип любых коммерческих отношений, что даже удивительно, что приходится его объяснять.
Поле ввода, на платформе apple, android, и во множестве популярных web-фреймворках, ведет себя внезапно строго по style guide платформы/фреймворка.
То есть, есть документ, в котором рассказано, каким должно быть поведение. Конечно, базовые случаи, типа при вводе «а» появляется именно «а», видимо нужно проверить, но кажется, такого рода проверки пишутся один раз для всего проекта, по одному комплекту на один тип ui-контрола, не? При добавлении нового нового view/экрана/итд, вызывают готовый комплект базовых тестов для этого типа контрола.
Неужели еще актуальны примитивные кликбейтные практики, писать заголовки якобы "провоцирующие" на клик? Практики, которые не уважают читателя?
Ок, вот мне таки было интересно, открыл, нашел фамилию Келдыш, написал комментарий и закрыл.
везде где вижу "удобное" форматирование log message исправляю на "шаблон отдельно, значения отдельно".
Изначально, мотивация была именно такая - зачем каждый раз перед вызовом делать то, что с какой-то вероятностью не потребуется. Но сейчас кто смотрит на эти копейки эффективности.
В какой-то момент, эта мотивация дополнилась тем, что протоколирование - это не всегда "строки текста". Сколько лет уже продвигается ELK и прочие технологии сбора/анализа/итд? Форматирование в человекочитаемую строку может быть вообще не потребуется, или это сделают где-то там, в каком-нибудь ELK, причем не только для debug, но вообще для всего.
Причем, сегодня про "такой поворот" может быть даже никто и не думает, а через год, вместо того, что бы в условно одном месте заменить log writer, будут устраивать ревизию всему коду.
Кажется, сейчас разобраться с каким-либо популярным в текущий момент "упаковщиком всего нужного в один бинарник" для "вашего любимого инструмента разработки" проще и выгоднее (по затрате усилий), чем писать клиентские приложения для OracleDB на C/C++
И не могу промолчать уходя немного в оффтопик: довелось длительное время (лет 10, наверное) внедрять и сопровождать продукт, у которого в качестве базы данных Oracle DB, и на фоне вот того опыта, слова "должен быть какой-то из продуктов Oracle, включающий OCI", у меня вызывают нервный смех. Прекратил всего этого касаться я когда еще не перешли целиком на 12c, а только присматривались. У версий 10 и 11, с вот этим все очень-очень-очень всё непросто, и может быть множество разных неожиданных фокусов даже если у сервера базы и клиента разные patch level. Другими словами, я не верю, что в реальной жизни можно полностью исключить какую-либо установку чего-либо из продуктов Oracle на компьютер с клиентским приложением. В тоже время, могу легко представить, что есть четки процедуры развертывания/обновления клиентских мест, но тогда известен набор "что должно быть точно", и опять-же, гораздо эффективнее, расширить этот набор, добавив требуемые библиотеки, а утилиты разрабатывать используя удобные инструменты.
Обычно люди делают инструмент для решения какой-то задачи. Какие задачи с использованием вашего языка будет решать лучше (проще, удобнее, приятнее, итд), чем с использованием любого другого уже существующего языка?
Человек написал статью на популярном ресурсе — для меня это означает, что попросил обратную связь. Я эту обратную связь ему даю, да и вы, по сути делаете то же самое.
— «опыт, это то, что ты получаешь, вместо того, что хотел». Применяя к текущей ситуации — хотел сделать супер-пупер инструмент, а получил опыт.
— кроме тех случаев, когда собственная ошибка приводит к гибели.
Применяя к текущей ситуации — «гибели» заметного количества времени и сил, вложенных в такой проект.
Мой вывод на основе той информации что я вижу простой: свой проект в текущем виде остановить, найти наиболее близкий по вкусу живой проект и прикладывать усилия туда.
Если цель проекта в первую очередь «получить опыт», то участие в живом проекте, позволит достингуть этой цели меньшими затратами, с высокой вероятностью опыт будет «более полезный».
В качестве бонуса будет то самое необязательное «проект в проде», откуда можно будет зачерпнуть очередную порцию энтузиазма на следующий проект.
Продолжение пиления своего велосипеда, я оцениваю, как тупиковый сценарий — начальных запал иссякнет, в обмен на это будет кучка разрозненных знаний вида «нахватался по верхам» и выгорание.
Оглянитесь вокруг — есть много, нет МНОГО языков. Популярные, можно пересчитать по пальцам на руках. За каждым из них — большая история, и если переводить в человеко-часы, вообще сложно оценить.
Посмотрите молодые (5-6 лет) растущие языки, с чего они начинались, и на каких усилиях они растут. Всё это, если не прямо сейчас, то очень скоро начнет «давить» не энтузиазм начинателя нового языка.
«но есть нюанс».
Я бы сказал, что в общем случае — нет. Можно сделать 100500 велосипедов, так ничему и не научиться. А в тяжелом случае, еще разбить себе лоб, в ходе испытаний очередной кривой самоделки.
Двигатель прогресса — человек, который разобрался в теме лучше/глубже, чем все, кто брался за эту тему до него. На мой взгляд, не принципиально, он смог это только за счет целеустремленности или посмотрел на задачу с нового ракурса. Важно, что сделал лучше.
Допустим. Как найти опытного напарника на ревью реализации нового языка?
ой, подождите… Если отправить пулл-реквест в уже существующий проект, его обязательно кто-то посмотрит, и скорее всего, это будет более опытный разработчик?
Наверное, это у меня такая проф.деформация, и слишком много по жизни приходилось копаться в чужом коде, который вроде работает в каких-то частных случаях, но выглядит отвратительно, что если через год-два-три изменяются требования, то возникает вопрос — нам действительно будет дешевле модифицировать «вот это»?
— это основная проблема для новичка. Это как «можно сделать хорошо, быстро, недорого — выбирайте любые два». В случае новичка — будет чудо, если у него получится хотя бы одному из трех требований удовлетворить. Поэтому, я убежден (никому не навязываю, но считаю важным озвучить) — если основная цель «научиться. разобраться, понять» — нужно взять уже что-то хоть в каком-то виде цельное-живое-рабочее, брать по «одной теме CS», и модифицировать это самое живое рабочее, разбираясь, почему границы между бекенд/фронтенд в этом случае провели именно так, почему лексер именно так написан, почему грамматика такая, когда их вон сколько разных?
При таком подходе, шансы того, что хоть в какой-то теме получится разобраться гораздо выше, чем если перед глазами десяток тем, и любой шаг вправо/влево, ломает весь мир.
А как это работает? Если человеку хочется писать код, хочется, что бы код запускался — ему не нужен Хабр, ему вообще никто не нужен.
Как только возникает мысль кому-то рассказать — это один из способов получить какой-то взгляд со стороны. Вот такой взгляд со стороны получен.
Добро пожаловать в реальный мир
Но я не понимаю вашего вопроса «зачем?». Ровно как и не понимаю зачем вообще создавать новый язык в 2021 году.
Язык — это инструмент. Зачем еще один инструмент, ни из статьи ни из ответов не понятно.
Поэтому простой короткий вывод — не зачем. И простая короткая рекомендация — прежде чем делать что-то совсем новое, попробуйте разобраться с чем-то, что уже используют люди. У всего есть недостатки, и того, что open source, есть возможность недостатки исправить. Это гораздо более достижимая цель, которая даст гораздо больше общей пользы, чем убить кучу сил и времени на новое, никому ненужное произведение.
Лично я минусовал по двум причинам:
— в надежде, что человек задумается «а почему минусуют, что не так?»
— однообразные комментарии, похожие на копипасту слов из статьи и соседних своих же комментариев.
«Критикуя предлагай»: Гораздо лучше найти наиболее близкий по духу/идее/итд проект и помогать его развитию. И с точки зрения достижения результата (этим будет пользоваться кто-то еще), и с точки зрения получения опыта, и с точки зрения разобраться, и с еще кучи других аспектов, вплоть, до улучшения мира в целом.
Что я потерял, кроме того, что мне перестали присылать тупые предложения о работе, которая мне не интересна?
Весомую часть проблемы автор поста сформулировал в начале — описания товаров плохие. У продавца нет стимула улучшать описание. С факта продажи зарабатывает продавец (платформа, дистрибьютор, производитель). И если вся эта цепочка не может обеспечить «хорошую витрину», какие шансы, что у активные покупатели, и заинтересованная платформа (поисковый движок) сможет?
У меня вопрос звучит иначе — прежде чем что-то улучшать, нужна цель и метрики.
Проблема в том, что магазинам не нужно «улучшать поиск».
Как в известном выражении: «людям не нужны дрели, им нужно картину на стену повесить»
Есть монстры, тот же Маркет, Озон, Вайлдберис — у них свои большие команды разработки. У следующих, крупных — видимо тоже.
Есть «серединка» — они, вероятно, аутсорсят всякое у крупных студий/команд.
И есть небольшие — они, кажется, или не парятся, используют то, что дает платформа (битрикс, шопифай, магенту), или находят фрилансеров (небольшие команды).
Как бы то ни было — в рамках онлайн магазина есть масса вопросов «что сделать лучше», какое место в этой массе занимает именно «сделать лучше поиск»?
Что бы ответить на этот вопрос, нужно четко понимать: сколько «денег» даст улучшение поиска, и сколько денег стоит это улучшение, и как эти выгоды-затраты соотносятся с другими вопросами.
Когда, скажем, интегратор/монтажник, на основе своего опыта рекламирует систему производителя-партнера, интересно читать даже если не рассказывают о минусах/сложностях.
А когда просто накидали красивых слов, которые вроде бы похожи на правду — фигня получается, а не реклама
Если возникает вопрос что проверять, ответ на этот вопрос нужно искать не в рамках тестирования. И это очень важно понимать особенно новичку в тестировании.
Не вижу никакой проблемы, если тестировщик обратится к аналитику, продакту, и уточнит — «вот тут что должно быть?».
Если продолжить тезис про поля ввода из соседней ветви:
— все поля ввода одинаковые, текст, максимальный размер введенного?
Если, например есть, поля ввода с валидаторами, где-то за рамками тестов ведь должно быть записано «в этом поле разрешены только цифры», «в этом поле — месяц, 1-2 цифры»? Если такое не записано, как тестировщик может написать тест на ввод месяца в текстовое поле? Он должен проверять все варианты? Какие из вариантов считать правильными, какие нет? «январь», «янв», «01», «1», какие?
К большому сожалению, ситуация когда приходится пользоваться не очень качественным продуктом (сторонняя библиотека — продукт, которым вы пользовались, наличие документации, её актуальность — один из критериев качества) распространена шире, чем хотелось бы. На мой взгляд выход из этой ситуации следовать трем пунктам
* определить для себя нижний уровень качества
* всегда выбирать более качественный продукт в рамках бюджета
* если по итогам всех выборов и оценок не удается достичь минимального уровня, либо не браться за задачу, либо пересматривать бюджет, либо пересматривать задачу.
По сути это ровно то же самое/, что я пытаюсь донести в соседних комментариях — без четкого понимания «что должно быть в результате», не вижу вариантов хорошо решить задачу тестирования.
Тест — это проверка. Идеи как проверить, наверное нужны. Но в статье же, по сути, о том, что «если непонятно, что проверять, какие могут быть идеи»?
Своими комментариями пытаюсь донести, что если нет понимания что проверять, то ответ на этот вопрос нужно искать не за пределами проекта, а внутри.
Если взять семейство agile-методик, у которых ключевой момент — короткие итерации, то насколько короткой итерацию не делай (хоть вообще один день), всегда есть «заказчик», «исполнитель», «ожидаемый результат». Ожидаемый к концу итерации. Записывают его на доске, в issue или просто встретившись утром у кулера обмениваются парой-тройкой фраз, если исполнителю не будут понятно, что от него ожидают — скорее всего, он сделает
какую-то фигнюне то, что ожидают.Мне, как заказчику, нужен результат, за фигню я не готов платить.
Я, как исполнитель, ровно в той-же степени хочу выдать результат, если, конечно, мне важно, что бы за мою работу заплатили.
Очень странно рассчитывать, что за фигню будут платить. Еще более странно платить за фигню, хотя окружающая действительность как бы говорит, что так поступают чаще, чем хотелось бы. Успокаивает только то, что ожидаемый результат платят значительно больше (на порядки?) чем за фигню.
Это настолько общий принцип любых коммерческих отношений, что даже удивительно, что приходится его объяснять.
То есть, есть документ, в котором рассказано, каким должно быть поведение. Конечно, базовые случаи, типа при вводе «а» появляется именно «а», видимо нужно проверить, но кажется, такого рода проверки пишутся один раз для всего проекта, по одному комплекту на один тип ui-контрола, не? При добавлении нового нового view/экрана/итд, вызывают готовый комплект базовых тестов для этого типа контрола.