Будет большой Стейт компонента.

если у тебя большой стейт, то это повод задуматься, ну а так да

я уже забыл в чем проблема)

приветы

что нового интересного?

что нового интересного?

ничего, все в ФП ушли

относительно свежее https://www.quora.com/What-resources-does-Alan-Kay-recommend-for-learning-real-object-oriented-programming

с Кеем в комментах конечно же

с Кеем в комментах конечно же

Кей вездесущий

ну не вездесущий

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

потому что я ищу и скидываю)

еще б читать начать самому ?

вообще просто всем в закладки: https://www.quora.com/profile/Alan-Kay-11

Такой вопрос по тестированию. Прочитал статью по тестовым двойникам(фейки, стабы, моки). Сделал вывод, что по факту, использование моков/стабов чаще всего говорит об неабстрактности кода и привязки к конкретной реализации, а в идеально спроектированной системе можно обойтись фейками. Так ли это?

Такой вопрос по тестированию. Прочитал статью по тестовым двойникам(фейки, стабы, моки). Сделал вывод, что по факту, использование моков/стабов чаще всего говорит об неабстрактности кода и привязки к конкретной реализации, а в идеально спроектированной системе можно обойтись фейками. Так ли это?

что такое неабстрактность кода? Как человек, писавший 1,5 года юнит тесты и код по ТДД скажу: чем больше нужно создавать тестовых двойников, тем хуже. В основном это будут стабы

кроме того, фейки в контексте юнит тестирования - это генерик термин.

Т.е. то, что ты сказал - похоже на бред. То, что моки - зло - это ясно. То, что стаб - зло, это не так ясно. Они являются злом только когда их много. Термин Фейковый ххх обозначает фактически стаб

open The Art of Unit Testing book

and read this book

ну даже по этому https://martinfowler.com/bliki/TestDouble.html fake != stub

кроме того, фейки в контексте юнит тестирования - это генерик термин.

Нет

Такой вопрос по тестированию. Прочитал статью по тестовым двойникам(фейки, стабы, моки). Сделал вывод, что по факту, использование моков/стабов чаще всего говорит об неабстрактности кода и привязки к конкретной реализации, а в идеально спроектированной системе можно обойтись фейками. Так ли это?

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

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

Могу предложить статью в тему https://8thlight.com/blog/uncle-bob/2014/05/14/TheLittleMocker.html

Нет

т.е. ты сичтаешь, то, что написал Ошеров в первом издании - устаревшей инфой?

т.е. ты сичтаешь, то, что написал Ошеров в первом издании - устаревшей инфой?

Не знаю кто такой ошеров

https://books.google.de/books?id=jyMZNlR_mcQC&lpg=PA118&dq=inauthor%3A%22Roy%20Osherove%22%20%20Begriff%20Fake%20wurde%20in%20Kapitel%204%20als%20ein%20allgemeiner%20Begriff&hl=de&pg=PA118#v=onepage&q=inauthor:%22Roy%20Osherove%22%20%20Begriff%20Fake%20wurde%20in%20Kapitel%204%20als%20ein%20allgemeiner%20Begriff&f=false

Definition A fake is a generic term that can be used to describe either a stub or a mock object (handwritten or otherwise), because they both look like the real object. Whether a fake is a stub or a mock depends on how it’s used in the current test. If it’s used to check an interaction (asserted against), it’s a mock object. Otherwise, it’s a stub.

ну даже по этому https://martinfowler.com/bliki/TestDouble.html fake != stub

Ну вот же

первоисточник по юнит тестированию

Я понял кто такой Ошеров, и он не первоисточник)

т.е. ты сичтаешь, то, что написал Ошеров в первом издании - устаревшей инфой?

мое мнение - в попытке увязать эти термины ты упускаешь суть - суть в снижении связанности. Моки не зло - это способ тестирования взаимодействия контрактов. Если у тебя много моков - значит много контрактов - значит высокая связанность кода и от того он становится более чувствителен к изменемниямм

мое мнение - в попытке увязать эти термины ты упускаешь суть - суть в снижении связанности. Моки не зло - это способ тестирования взаимодействия контрактов. Если у тебя много моков - значит много контрактов - значит высокая связанность кода и от того он становится более чувствителен к изменемниямм

так я не понял, фейк в современном предствлении - это общний термин длай моков и стабов или таки отдельный?

так я не понял, фейк в современном предствлении - это общний термин длай моков и стабов или таки отдельный?

вопрос из той же оперы - дай точное определение юнит тесту. Их много

так что зависит от трактовки)

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

вопрос из той же оперы - дай точное определение юнит тесту. Их много

я тебе привел выше цитату из ошерова. приведи мне свою

я тебе привел выше цитату из ошерова. приведи мне свою

тебе привели ссылку на фаулера

> Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an InMemoryTestDatabase is a good example).

а вот TestDouble - это больше похоже на общий термин

> Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an InMemoryTestDatabase is a good example).

т.е. мы приходим к выводу, что товариша ошерова нужно по почкам битьза такие определениай фейков

т.е. мы приходим к выводу, что товариша ошерова нужно по почкам битьза такие определениай фейков

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

это всего лишь интерпритация и своя формулировка. Ничего страшного

главное в итоге придти к связи между TestDouble/Fake objects и связанностью.

а то рекомендую все "делай меньше моков" и народ потом не понимает что и как... а смысл в том что бы количество зависимостей уменьшать

и характер зависимости учитывать

Выделяете ли вы исключения в отдельную папку? И если не выделяете, используете ли суффикс Exception?

суффикс да