А еще разработчик видит кучу шагов на которых программа может сломаться. Так что от конкретного разработчика зависит. Но если и переходить, то переходить на автоматическое тестирование безусловно.
Не знаю, как в ИБ, а в обучении программированию и архитектуре ПО, я против мегапроектов. По двум причинам:
1) Когда над проектом работают все, то никто не видит целостной архитектуры. У всех кусочные знания. Я в свою бытность студентом (да и сейчас зачастую) больше всего знаний получал, когда делал проект от и до сам. Даже если я его не доделывал. Я собирал все грабли, а не треть и именно это позволяло глубже расти. А в групповых проектах я зачастую занимал либо роль человека который делает проект и все его сдают (если проект был интересен), либо роль лодыря, который списывает.
2) Я считаю, что в бытность студентом важно набить себе много шишек, пройтись на своем опыте по максимальному количеству граблей, суметь сделать из этого правильные выводы, и никогда больше так не делать. Следовательно время жизни студенческого проекта лучше даже до двух семестров не доводить (хотя один проект можно и нужно — диплом называется). Студенчество — то время, когда важен опыт, а не результат, когда студент прогрессирует достаточно быстро, чтобы ненавидеть свой код четырехмесячной давности. И исправлять его — так себе затея. Лучше просто выкинуть. Если это не курс по рефакторингу. На мегапроектах выкидывать код сложно, а делать это нужно постоянно.
2*)Вы представляете с каким количеством говнокода придется сталкиваться студентам, которые входят в эти мегапроекы? И ведь многие из них будут думать, что так и надо! Многие будут думать, что они присоединяются к мегапроекту нормально написанному, и что в этом спагетти-говнокоде есть какой-то скрытый смысл. А как-то дописывать логику туда как? Только одним способом — наворачивать новые костыли поверх всего этого. Вы таких специалистов хотите готовить? Их и так полно вокруг. В нормальную команду чистоплюев хрен попадешь. Все думают, что хреново написанный код с кучей багов — это норма жизни.
Так что я за курсовые проекты. Индивидуальные. С качественной обратной связью от преподов (Хотя преподов жалко конечно… Я бы сам не смог так).
Печалит, только, что Kotlin еще даже не в бете (хотя уже близок!). А там еще года полтора-два нужно будет ждать, пока им реально можно будет пользоваться.
хотя его можно назвать и Системное тестированием, разница между ними не такая большая
Согласен. Я бы разницы не заметил. Хотя если верить википедии — то она есть
программисты ручных тестов не делали никогда
Программисты постоянно занимаются ручным тестированием, если не пишут автотестов (видимо буду первым, кто назовет их так в вашем присутствии). Запускают написанную программу — и смотрят все ли правильно работает. Они их редко оформляют в виде тестовых сценариев, или проводят ручные регрессы — но тестирование фич проводят.
Это называется GUI-тестирование
Да, тоже можно… Всяко понятнее, чем «автотесты». Но из контекста должно быть понятно, что имеется ввиду не ручное GUI тестирование…
цитата выше «QA никогда не пишет автотесты»
Согласен… Бред полный написан. Не разглядел поначалу.
Вообще посыпаю голову пеплом… С вашей стороны на протяжении этого треда в подавляющем большинстве случаев была корректная терминология.
Просто я неправильно прочитал вот эти строки вещи:
Автотесты и Юнит-тесты это две большие разницы
Возможно у вас просто другое понимание что такое автотесты и вы имеете в виду unit-тесты или интеграционные тесты
А затем вы приправили их вот этим
И ни разу не слышал чтобы тесты написанные программистами назывались автотестами
Вообще у меня вызывает баттхерт, когда люди говоря «автотест» подразумевают именно «автотест написанный QA-инженером», а такое случается постоянно. И это не правильно.
Автотест, согласно присланной вами же ссылке это и unit-тест и интеграционный, вне зависимости от того кем написан. Главное, чтобы его можно было запускать без участия человека.
Вам пытаются дать понять, что вы терминологически запутались. Именно терминологически — описанный вами «автотест QA» является ни чем иным, как интеграционным функциональным тестом. А с применением каких технологий (Selenium / SoapUI / Java NIO / assembler) и кем написанно — не важно.
Этот терминологический нонсенс вообще удручает.
В какой то момент, у QA инжинеров появились инструменты создания автоматических тестов. Они стали называть их «автотестами», чтобы отличать от ручных. Но потом, почему-то..., они начали противопоставлять их unit-тестам, чтобы отличать их от тех, что пишут программисты. А слова нового не придумали. Хотя unit-тесты тоже являлись автоматическими уже тогда… И уже тогда программисты писали не только unit, но и интеграционные тесты.
С тех пор прошло немало времени, а QA инженеры до сих пор говоря «автотест» уверенны, что их все должны понимать. И нам приходится додумывать, что скорее всего имеются ввиду Selenium тесты (по-моему за ним еще большинство, хотя конкурентов хватает). Называли бы их тогда Selenium тестами, и не запутывали всех вокруг.
Причем разграничивать тесты по тому — кто их написал вообще бессмысленно. Я уловил вашу мысль, что QA-инженер скорее напишет более грамотный тест-кейс, но к классификации тестов, как таковых, это отношения не имеет.
Этот загадочный «менталитет» — всего лишь следствие большого количества нефте-бабла и слабого контроля за результатами его расходования. В итоге «процессов» как таковых нет, и строить их незачем. Нужен деньгооборот и видимость деятельности. Спрашивать качество с менеджера никто не станет — только функциональность. А для этого хватает программеров и тестеров среднего и даже ниже среднего уровня. Предпосылок требовать качество, а не скорости от подчиненных нет никаких.
Короче в индустрии все хорошо. Деньги пилятся, люди учатся, оставляя тонны ошибок в загибающихся проектах. А выучившись те, кому копошиться в говнокоде надоедает… оставляют посты и комментарии на хабре с непониманием как из этой ситуации выбираться…
Будут или нет экспериментаторы на проекте зависит не от самих экспериментаторов, а от техлида и менеджмента. Если им пофиг на качество кода — то в экспериментаторы и говнокодеры переметнутся даже самые терпеливые из перфекционистов. Если конечно останутся в компании.
Замечательно у них поставлен PR в компании. По тем же принципам бумажных стандартов и без включения мозга? Я к тому, что количество копипасты в комментариях от товарища mao1985 зашкаливает за любые разумные пределы.
Ок, каюсь, не пробовал использовать Anorm без Play. Потому и написал так обтекаемо про «возможные» сложности этого процесса. Вообще мне синтаксис и подход Skalike кажется чуточку более стройным, чем у Anorm, и уже этого хватило, чтобы поделиться знаниями о существовании этой библиотеки с хабром. Возможно, узнав о ней, некоторые скалисты озадачатся уже вопросом об использовании Skalike в Play =).
Мне кажется тут разница как раз в подходе. Промышленное оборудование в виде База + направленная антенна, против колхозной меш-сети на домашних роутерах. Если, конечно, изначальный пост был про постройку сети на хорошем оборудовании и с расчетами, то можно заставить работать предсказуемо.
Хотя, конечно, сложно сравнивать… Все-таки эти библиотеки из разных миров. Тогда уж нужно полностью сравнивать, приложения на Java+Spring+SpringJDBC vs Scala+Smth+ScalikeJDBC и те возможности, что предоставляют эти связки. А это уже на отдельную, причем холиварную, статью тянет.
Spring JDBC — отличная библиотека для Java. Погрязла в Spring глубже, чем Anorm в Play, но это не минус.
Если их сравнивать, то получится больше похожего, чем различий. Все-таки обе команды воплащают лучшие практики, просто на разных языках. Но парочку различий выделить можно.
Что в Spring JDBC сделано удобнее, чем в ScalikeJDBC:
Благодаря магии Spring, там удобнее работать с транзакциями. Но это, скорее благодаря Spring-IoC, который заворачивает через proxy в транзакции все, что в @Transactional. В скала DI не так популярен.
Что в ScalikeJDBC сделано удобнее, чем в Spring JDBC:
Благодаря магии Scala, параметры помещаются сразу в запрос. В Spring приходится сначала помечать :param_name в запросе, а потом передовать параметры отдельно. Благодаря этому в скала меньше визуального шума получается.
И все это будет работать в описываемых условиях крайне непредсказуемо… Лучше уж кабели протянуть один раз, чем думать почему у пользователей «интернет тормозит». Может погода влияет на сигнал… Может, две выключенных из разетки ноды меш-сети… Может просто 10 устройств подключившихся к одной ноде одновременно… Короче, намучался я однажды в подобной колхозной сети с большим количеством беспроводных состовляющих… Никому не советую.
1) Когда над проектом работают все, то никто не видит целостной архитектуры. У всех кусочные знания. Я в свою бытность студентом (да и сейчас зачастую) больше всего знаний получал, когда делал проект от и до сам. Даже если я его не доделывал. Я собирал все грабли, а не треть и именно это позволяло глубже расти. А в групповых проектах я зачастую занимал либо роль человека который делает проект и все его сдают (если проект был интересен), либо роль лодыря, который списывает.
2) Я считаю, что в бытность студентом важно набить себе много шишек, пройтись на своем опыте по максимальному количеству граблей, суметь сделать из этого правильные выводы, и никогда больше так не делать. Следовательно время жизни студенческого проекта лучше даже до двух семестров не доводить (хотя один проект можно и нужно — диплом называется). Студенчество — то время, когда важен опыт, а не результат, когда студент прогрессирует достаточно быстро, чтобы ненавидеть свой код четырехмесячной давности. И исправлять его — так себе затея. Лучше просто выкинуть. Если это не курс по рефакторингу. На мегапроектах выкидывать код сложно, а делать это нужно постоянно.
2*)Вы представляете с каким количеством говнокода придется сталкиваться студентам, которые входят в эти мегапроекы? И ведь многие из них будут думать, что так и надо! Многие будут думать, что они присоединяются к мегапроекту нормально написанному, и что в этом спагетти-говнокоде есть какой-то скрытый смысл. А как-то дописывать логику туда как? Только одним способом — наворачивать новые костыли поверх всего этого. Вы таких специалистов хотите готовить? Их и так полно вокруг. В нормальную команду чистоплюев хрен попадешь. Все думают, что хреново написанный код с кучей багов — это норма жизни.
Так что я за курсовые проекты. Индивидуальные. С качественной обратной связью от преподов (Хотя преподов жалко конечно… Я бы сам не смог так).
Согласен. Я бы разницы не заметил. Хотя если верить википедии — то она есть
Программисты постоянно занимаются ручным тестированием, если не пишут автотестов (видимо буду первым, кто назовет их так в вашем присутствии). Запускают написанную программу — и смотрят все ли правильно работает. Они их редко оформляют в виде тестовых сценариев, или проводят ручные регрессы — но тестирование фич проводят.
Да, тоже можно… Всяко понятнее, чем «автотесты». Но из контекста должно быть понятно, что имеется ввиду не ручное GUI тестирование…
Согласен… Бред полный написан. Не разглядел поначалу.
Вообще посыпаю голову пеплом… С вашей стороны на протяжении этого треда в подавляющем большинстве случаев была корректная терминология.
Просто я неправильно прочитал вот эти строки вещи:
А затем вы приправили их вот этим
Вообще у меня вызывает баттхерт, когда люди говоря «автотест» подразумевают именно «автотест написанный QA-инженером», а такое случается постоянно. И это не правильно.
Автотест, согласно присланной вами же ссылке это и unit-тест и интеграционный, вне зависимости от того кем написан. Главное, чтобы его можно было запускать без участия человека.
Этот терминологический нонсенс вообще удручает.
В какой то момент, у QA инжинеров появились инструменты создания автоматических тестов. Они стали называть их «автотестами», чтобы отличать от ручных. Но потом, почему-то..., они начали противопоставлять их unit-тестам, чтобы отличать их от тех, что пишут программисты. А слова нового не придумали. Хотя unit-тесты тоже являлись автоматическими уже тогда… И уже тогда программисты писали не только unit, но и интеграционные тесты.
С тех пор прошло немало времени, а QA инженеры до сих пор говоря «автотест» уверенны, что их все должны понимать. И нам приходится додумывать, что скорее всего имеются ввиду Selenium тесты (по-моему за ним еще большинство, хотя конкурентов хватает). Называли бы их тогда Selenium тестами, и не запутывали всех вокруг.
Причем разграничивать тесты по тому — кто их написал вообще бессмысленно. Я уловил вашу мысль, что QA-инженер скорее напишет более грамотный тест-кейс, но к классификации тестов, как таковых, это отношения не имеет.
Короче в индустрии все хорошо. Деньги пилятся, люди учатся, оставляя тонны ошибок в загибающихся проектах. А выучившись те, кому копошиться в говнокоде надоедает… оставляют посты и комментарии на хабре с непониманием как из этой ситуации выбираться…
На самом деле со Slick еще не работал, сравнить не могу.
Если их сравнивать, то получится больше похожего, чем различий. Все-таки обе команды воплащают лучшие практики, просто на разных языках. Но парочку различий выделить можно.
Что в Spring JDBC сделано удобнее, чем в ScalikeJDBC:
Что в ScalikeJDBC сделано удобнее, чем в Spring JDBC: