Java кабала

Для всех тех, кто не смог подключиться к трансляции: https://www.youtube.com/watch?v=15MCsGbtxt4 Ссылка на курс: https://javakabala.ru/javase

Друзья, ссылка на трансляцию: https://youtu.be/izuE7LmMZ3g Начало в 19:30

Друзья, следите за анонсами у меня в инстаграм - https://www.instagram.com/fonatik_kabal/ Сегодня в 19:30 по мск проведу первую лекцию-вебинар, на которой расскажу, для кого этот курс, немного материала из первой лекции и немного о том, зачем вообще нужно программирование

Задачка перед сном (теперь кто-то из вас не уснет, пока не решит). Сейчас посмотрим, кто уже проходил тему исключений. Что будет выведено в консоль?

Вы спрашивали когда же курс, когда когда... Да вот сейчас! Курс готов! Подать заявку можно тут: https://javakabala.ru/javase Обучение начнется 7го ноября. Количество мест ограничено.

Ребятки, считаю, что кому-то это будет полезно! Есть вакансии для джунов: https://hh.ru/vacancy/47972305 https://hh.ru/vacancy/46407793 Мне предложили разместить их здесь, т.к. многим из вас они могут быть интересны. Не смотрите на всякие требования типа год опыта, или ещё смешнее «опыт управления командой». Просто почитайте что предстоит делать, и, если нравится, просто пробуйте и ничего не бойтесь. По всем вопросам обращайтесь https://t.me/tef_sofia

Друзья, работа над курсом близится к завершению! Курс будет доступен очень скоро, осталось довести до совершенства некоторые моменты. Не забывайте, что прежде, чем откроется продажа курса, я проведу первую бесплатную лекцию для всех желающих. Также будет подробное описание курса, но чуть позже. Многие спрашивали про консультации и индивидуальные занятия. Они тоже есть и доступны уже сейчас. Welcome https://javakabala.ru/

​Продолжение темы тестирования своего говнокода NOTE: На картинке API тесты находятся выше интеграционных. Но это условность. Все зависит от приложения и количества входных / выходных контроллеров. У вас может быть богатое REST API и ноль интеграций. Тогда у вас будет тонная API тестов и ни одного интеграционного. И наоборот, у вас может быть парочку web сервисов, и хуйва кукуева интеграций (например, используйте bpm движок). Моя практика говорить, что в ряде случаев, API тесты возобладают над интеграционными. Особенно, когда мы разрабатываем ресурсные сервисы. Есть такая вещь, называется пирамида тестирования. Она говорит нам о том, в каком объеме мы должны писать те или иные тесты. Теперь давайте посмотрим на пирамиду сверху вниз. Мы видим, что наверху пирамиды располагаются UI тесты. К ним можно отнести мануальное тестирование. В идеале, у нас вообще не должно быть ручного тестирования. Но зачастую, оно есть. Как обычно решается эта проблема? Правильно - автоматизация. Например, тестами на selenium. Логично предположить, что если мы детализируем нашу пирамиду, то автоматизированные UI тесты будут ниже, чем мануальное тестирование. Давайте опустимся еще ниже, где мы видим интеграционные тесты. Эти тесты задействуют большое количество функционала, а значит имеют очень много зависимостей, что приводит к их частым падениям. Интеграционные тесты призваны проверять интеграции между различными системами - сетевые доступы, контракты, пермишены и тд. Если мы детализируем нашу пирамиду еще, то увидим ниже интеграционных тестов - контрактные тесты (API). Это тесты, которые в изоляции тестируют контракты вашего API. При этом, весь функционал должен быть замокан или застабирован. Если мы пойдем еще ниже, то увидим компонентные тесты. Это тесты, которые покрывают ваш компонент (это абстрактная вещь, под компонентом как правило понимается функционал). В самом низу, мы увидим родненькие unit тесты. Это тесты, которые проверяют наши методы в изоляции от любых зависимостей, подразумевая, что зависимости работают корректно. Чем ниже мы спускаемся по пирамиде тестов, тем большее количество тестов подразумевает каждый слой. Поэтому, в первую очередь, мы должны все обложить маленькими, простыми и компактными unit тестами. Затем уже задуматься о модульных тестах, а уже затем, приступать к тестированию API (контрактов). Как правильно, тут наша задача заканчивается. Все, что выше контрактных тестов обычно пишут QA. В следующем посте расскажу вам, как правильно писать unit тесты, потому что это отдельный вид искусства. И я очень серчаю, когда люди пишут убогие монструозные юниты, не понимая, какую проблему они ими решают и зачем вообще их пишут.

Ураа, ураа! Вышел первый подкаст с моим участием! Обсуждаем тему ошибок начинающих программистов! Всем рекомендую к просмотру! Длительность 28 мин. https://www.youtube.com/watch?v=wtjtO0J2I9o P.S. кому интересна тема мобильной разработки или frontend - подписывайтесь на канал Вовки! https://t.me/evstratov_online Не забудьте подписать на youtube канал, т.к. это не последнее совместное видео!

Кабалисты, вот нас уже и 100к в тикток! Всем огромное спасибо за вашу активность! Всех целую, сегодня ждите продолжение по тестам!

Комментарии можно оставит тут 👉

​Ребят, моя жена продаёт разные штуки и носки в том числе 😁 я придумал дизайн, зацените, что думайте🤡 По мотивам ролика: https://vm.tiktok.com/ZSedhhbj2/

Комментарии сюда...

Подошла тема тестов. Да да, вы не ослышались, мы пишем тесты. Я вам больше скажу, тесты это такая же часть нашей жизни как вода, воздух и код. Тестов существует огромное количество и они отличаются целью, технологиями, покрытием и тд. Я много прохожу собеседований, и мне всегда очень обидно, что за спринг и ссаные коллекции меня спрашивают по 20-30 минут, но ни одного вопроса по тестам! Но как тогда вы блять делаете качественный продукт, если вы не задаете мне ни одного вопроса на эту тему? Для меня это звоночек... Значит в компании культура доставки ценности не очень развита, да и в целом процессы разработки ПО страдают. Давайте поговорим в целом про тесты, не вдаваясь в подробности. Задайте себе вопрос: "зачем они нужны" и попробуйте ответить. Не читай дальше!!! Подумай блять! Ладно, давай я... Первое, запомните навсегда: пока у вас не прошли все написанные тесты, вы не можете быть хоть как-то уверенным в том, что ваш код работает, как вы задумали. Вы можете только фантазировать, что он работает. Но пока все тесты успешно не пробегут, это лишь ваши догадки. Второе, запомните как отче наш: тесты не говорят о том, что у вас нет багов, тесты говорят о том, что баги есть!!! Если у вас успешно прошли все тесты, это не значит, что нет бага. Просто, вероятно, вы не написали тест, которые проверяет этот сценарий. Но если тест упал - значит есть баг!!! Тесты это сигнализация, которая дает нам моментальную обратную связь о том, что мы что-то сломали. Тесты помогают нам смело менять и рефакторить существующий код, не боясь сломать его, т.к. хорошо написанные тесты начнут падать, если вы что-то сломаете своими изменениями. Это очень помогает, когда на проект приходят новички, которые не знают всех нюансов и тонкостей, и как правило, чаще всего что-то ломают. В этом случае тест сразу скажет нам об этом и такое ПО не будет релизиться до тех пор, пока не будут устранены все проблемы. Есть еще очень один важный нюанс: хорошо написанные тесты помогают понять намерения разработчика. Это практически тоже самое, что читать Javadoc. Тесты это сценарии, которые говорят вам, как ваш код должен работать с точки зрения клиента (под клиентом подразумевается не только end user, а также другой код, который вызывает ваш). Когда вы читаете такие тесты, вы как будто читаете рассказ о тестируемом коде, и уже исходя из тестов можно понять, как код работает. Тесты - это инструмент, который помогает нам повышать качество нашего продукта. Если вы не пишете тесты, можете выкинуть в помойку ваши каракули. На рабочем столе есть корзина, вот туда... В следующих статьях подробнее разберу типы тестов и пирамиду тестирования.

https://vm.tiktok.com/ZSeeQqBq5 Фанатики кабала, как и обещал - видео с результатами открытого резюме😄 два раза банили его 😢

А вот и ссылочка, которую вы так не ждали: https://instagram.com/fonatik_kabal?utm_medium=copy_link