Я так понял, что там только интеграционные тесты на PHP. А модули покрывали тестами? Рекламирую для этих целей библиотечку матчеров от коллеги: https://github.com/aandryashin/matchers
Пользование поиском программиста — это то же самое, что умение пользоваться справочником у любого инженера. Опытный программист часто знает что он ищет, поэтому способен отсеивать лишнее. Начинающий программист ищет хотя бы какое-то решение, поэтому часто берет первое попавшееся.
Тестовое покрытие — это степень, в которой ПО прошло интеграционное тестирование.
Почему только интеграционное? Куда делось юнит-тестирование, компонентное тестирование и остальные?
Очевидно, что высокое покрытие — хорошая штука.
Не очевидно. Хорошая штука — достаточное покрытие. Слишком большое количество тестов приведет к тому, что вырастут издержки на поддержку тестов при изменении кода.
Да, конкретные данные дать не могу, т.к. NDA. Не хочется тут голословно утверждать, что лучше. Я лишь хотел сказать, что в нашей конкретной задаче аггрегирования больших объемов сообщений в реальном времени, MongoDB показывается себя лучше. Возможно, есть задачи, где Hazelcast выигрывает. Если вы посмотрите, где я работаю, то поймете, что у меня нет никакого интереса рекламировать или наоборот ни то, ни другое.
Кластер просто разваливается. Перестает принимать новые данные, ноды друг друга не видят, хотя сеть в порядке. Правда у нас RPS что-то в районе 1000. :)
Может кому интересно, но MongoDB в качестве кластера локов и очередей работает и не разваливается при гораздо большей нагрузке, чем Hazelcast. И MongoDB гораздо устойчивее к падению датацентров по питанию и сети, чем Hazelcast. Это утверждение основано на реальной эксплуатации сервисов с InMemory гридами.
Опыт других фреймворков (например, Play, где Java заменили на Scala), в которых был сделан переход с одного языка на другой (в Angular 2 Javascript заменен на TypeScript), показывает, что для эффективного использования технологии все равно нужно изучать новый язык. Так что, на мой взгляд, время все-таки придется потратить.
На декораторах (аннотациях) можно писать еще много чего полезного. Например, в Java на них построены популярные фреймворки тестирования JUnit и TestNG и фрейворк разработки больших приложений Spring Framework. Поскольку все больше бекенда переезжает на фронтенд, то и методы разработки больших проектов становятся все более востребованными. Angular 2 уже содержит фреймворк dependency injection и сдается мне, что через год-два использование таких штук будет уже стандартом написания больших фронтенд-приложений.
Почему только интеграционное? Куда делось юнит-тестирование, компонентное тестирование и остальные?
Не очевидно. Хорошая штука — достаточное покрытие. Слишком большое количество тестов приведет к тому, что вырастут издержки на поддержку тестов при изменении кода.