Ну не знаю... Тестировать через колоноскопию надо только то, что уже совсем не переделать, ИМХО.
Тесты это тоже код, тоже люди, может, даже отдельные. Видимость только для тестов означает, что метод не приватный, а хотя бы защищённый.
В простом случае, как в примере, не вижу смысла его тестировать отдельно, но, примем гипотезу, что он "сложный". Тогда это алгоритм. Алгоритмы хорошо пакуются в стратегии.
Сложную логику выносим в отдельный тестируемый класс;
Вставляем его в целевой;
Говорим себе спасибо, т.к. алгоритм можно протестировать отдельно;
Говорим себе спасибо, т.к. целевой класс можно тестировать с понятной заглушкой (а не стрёмным моком) для алгоритма, легко (и очевидно для окружающих) моделируя нужные крайние случаи его работы.
Я не могу себе представить, почему это будет проблемой. Но, если уж это и правда так, то это должны быть какие-то "SelfCheckTest". Однако, мне кажется, лучше уж, в таком случае, тесту принять вот такую гипотезу: публичный метод не вызывает никакой приватный метод, а если это не так, то тело приватного метода является неотъемлемой частью публичного, будто бы его никто и не выносил в отдельную функцию.
Собеседование - возможность показать себя друг другу "как есть". Всех устраивает - работаем, иначе ищем дальше... А задачи разбирать, лучше становиться - это на курсы. Там этим занимаются.
В третьем пункте я говорю не о том, что Вы комментируете. Влиять можно и сейчас. Ваш сервис становится концентратором знания о том кто кому больше доверяет. Эта информация может повысить качество уже существующих атак. Рано или позно она утечёт к тем, кому она так интересна.
"Не можешь победить - возглавь"
Может, вместо того, чтобы фильтровать отзывы по конкретному товару и ресурсу (а фильтрация - это скорее убывающая функция от набора критериев), создать сервис-бот, который поищет отзывы как "про" с применением лучших техник отсеивания ботов, лучших практик ранжирования отзывов и т.п. и предоставит мне отчёт с возможностью исключить (и переоценить в зависимости от этого) использованные источники, которым я не доверяю? Доверять такому результату всё ещё нельзя (а кому вообще можно? критическое мышление отключать нельзя), но так я получу сводку, которую сам бы строил теми же (или худшими) методами (с дополнительными субъективными ошибками и невнимательностью), только значительно дольше.
Допустим, что система реализована и набрала достаточную аудиторию для корректной (с точки зрения правил системы) работы.
Первое: мнения ботов я не вижу, это я понял.
Второе: мнение контакта А по вопросу X мне инетересно, но его мнение по вопросу Y (в силу его компетенции) меня уже не сильно интересует (можно сказать вес менения человека А меняется в пределах от 0 до 1 в зависимости от темы X) - без этого концепция "кругов" видится мне очень фрагментарной.
Третье: в случае утечки информации, злоумышленик получает контакты и "круги" доврия для построения наиболее эффективного вектора атаки.
Итого: при серьёзных рисках, система прелагает только фильтрацию от ботов с относительно быстрым построением нужного для этого "круга авторитетных мнений". И, мне кажется, сильно пеувеличивается возможность такой системы: какова вероятность, что на каком-то конкретном ресурсе по какому-то конкретному вопросу окажется мнение (хотя бы одно) человека из (хотя бы 3-его) моего круга?
Тут, ИМХО, вообще тонкий лёд. Что такое бизнес день? Рабочий день? Рабочий день - это вообще может быть часть часов, когда люди трудятся. А что с праздниками и переносами?
Звучит так, что я ожидаю что-то одно, а оно считает что-то другое. Или имя функции не отражает назначение, или в этой функции ошибки в расчете.
Надо было назвать getNumbeOfDaysBetweenTwoPointsOfTimeExcludingWeekend, ну или diffDatesExcludingWeekends
Ну и [SUNDAY, SATURDAY].includes(currentDayOfWeek) немного легче читать, чем предложенное условие
Про пункт DI. Мне кажется автор некорректно описал то, что имел ввиду. Я вот вижу, что его конструкторы принимают интерфейсы (что и требуется). А вот, в конфигурации контейнера он предпочитает ставить реализации (это конфигурация кода, а не сам код). И его можно понять - если везде прокидывать интерфейсы, то не получится в разные классы прокинуть разные реализации.
Ну не знаю...
Тестировать через колоноскопию надо только то, что уже совсем не переделать, ИМХО.
Тесты это тоже код, тоже люди, может, даже отдельные. Видимость только для тестов означает, что метод не приватный, а хотя бы защищённый.
В простом случае, как в примере, не вижу смысла его тестировать отдельно, но, примем гипотезу, что он "сложный". Тогда это алгоритм. Алгоритмы хорошо пакуются в стратегии.
Сложную логику выносим в отдельный тестируемый класс;
Вставляем его в целевой;
Говорим себе спасибо, т.к. алгоритм можно протестировать отдельно;
Говорим себе спасибо, т.к. целевой класс можно тестировать с понятной заглушкой (а не стрёмным моком) для алгоритма, легко (и очевидно для окружающих) моделируя нужные крайние случаи его работы.
Я не могу себе представить, почему это будет проблемой. Но, если уж это и правда так, то это должны быть какие-то "SelfCheckTest". Однако, мне кажется, лучше уж, в таком случае, тесту принять вот такую гипотезу: публичный метод не вызывает никакой приватный метод, а если это не так, то тело приватного метода является неотъемлемой частью публичного, будто бы его никто и не выносил в отдельную функцию.
<sarcasm>и дружеские визиты в ФемТех</sarcasm>
ну надо и надо, что Вы? :) что за «640 КБ должно хватить всем»
<sarcasm>Действительно! Вам платят за тестовое задание, Вы платите за его проверку и предоставление обратной связи ;)</sarcasm>
Озвучу непопулярное мнение )
Собеседование - возможность показать себя друг другу "как есть". Всех устраивает - работаем, иначе ищем дальше... А задачи разбирать, лучше становиться - это на курсы. Там этим занимаются.
Это был просто способ сказать, что "не подошёл" ;-)
В третьем пункте я говорю не о том, что Вы комментируете. Влиять можно и сейчас. Ваш сервис становится концентратором знания о том кто кому больше доверяет. Эта информация может повысить качество уже существующих атак. Рано или позно она утечёт к тем, кому она так интересна.
"Не можешь победить - возглавь"
Может, вместо того, чтобы фильтровать отзывы по конкретному товару и ресурсу (а фильтрация - это скорее убывающая функция от набора критериев), создать сервис-бот, который поищет отзывы как "про" с применением лучших техник отсеивания ботов, лучших практик ранжирования отзывов и т.п. и предоставит мне отчёт с возможностью исключить (и переоценить в зависимости от этого) использованные источники, которым я не доверяю? Доверять такому результату всё ещё нельзя (а кому вообще можно? критическое мышление отключать нельзя), но так я получу сводку, которую сам бы строил теми же (или худшими) методами (с дополнительными субъективными ошибками и невнимательностью), только значительно дольше.
Допустим, что система реализована и набрала достаточную аудиторию для корректной (с точки зрения правил системы) работы.
Первое: мнения ботов я не вижу, это я понял.
Второе: мнение контакта А по вопросу X мне инетересно, но его мнение по вопросу Y (в силу его компетенции) меня уже не сильно интересует (можно сказать вес менения человека А меняется в пределах от 0 до 1 в зависимости от темы X) - без этого концепция "кругов" видится мне очень фрагментарной.
Третье: в случае утечки информации, злоумышленик получает контакты и "круги" доврия для построения наиболее эффективного вектора атаки.
Итого: при серьёзных рисках, система прелагает только фильтрацию от ботов с относительно быстрым построением нужного для этого "круга авторитетных мнений". И, мне кажется, сильно пеувеличивается возможность такой системы: какова вероятность, что на каком-то конкретном ресурсе по какому-то конкретному вопросу окажется мнение (хотя бы одно) человека из (хотя бы 3-его) моего круга?
Зачем там типизация, если я всёравно где-нибудь, да напишу
t("page.helo"Мне бы больше хотелось что-то типа
t.page.hello/t.page.hello({name: 'world'})Кстати, переводы это не только
два килограммаперевод меток, но и направление текста, так ещё и вёрстку под конкртеный язык может понадобиться менятьУ господина получилось:
https://habr.com/ru/articles/828722/comments/#comment_27050996
Тут, ИМХО, вообще тонкий лёд. Что такое бизнес день? Рабочий день? Рабочий день - это вообще может быть часть часов, когда люди трудятся. А что с праздниками и переносами?
Звучит так, что я ожидаю что-то одно, а оно считает что-то другое. Или имя функции не отражает назначение, или в этой функции ошибки в расчете.
Надо было назвать getNumbeOfDaysBetweenTwoPointsOfTimeExcludingWeekend, ну или diffDatesExcludingWeekends
Ну и [SUNDAY, SATURDAY].includes(currentDayOfWeek) немного легче читать, чем предложенное условие
/s а если, вместо тележки использовать квадрокоптер, то можно писать кругами на полях )
Ну... Давайте обменяемся картинками:
/s
А что не наоборот?)
A - эй
B - би
...
It was a wonderful day - ит воз э вандерфул дэй
"зарезервировано для будущего использования" )
ещё можно вместо 0 и 1 использовать точку и тире ;)
default вычистится один раз на инстанс и будет передаваться одно и то же значение
Про пункт DI. Мне кажется автор некорректно описал то, что имел ввиду. Я вот вижу, что его конструкторы принимают интерфейсы (что и требуется). А вот, в конфигурации контейнера он предпочитает ставить реализации (это конфигурация кода, а не сам код). И его можно понять - если везде прокидывать интерфейсы, то не получится в разные классы прокинуть разные реализации.
не хватает ещё
А может это реклама литкода. Что такое литкод без, как Вы их назвали, макак? ;)