хотя сомневаюсь что у тебя выйдет юнит тесты в принципе писать

ну или ты войдешь в цикл "рефакторить что бы покрыть тестами -> покрывать тестами что бы рефакторить"

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

один eav это стильно молодежно делаем так ведь magento так делает (да и не только магенту)

Я гляжу тебя все не отпускает... хотя ты даже не читаешь ответы - а просто кидаешь на вентилятор. Но да я не гордый, я повторю. EAV решает свою конкретную задачу и делает это не плохо. Магента и другие примеры, я тебе скинул для примера. Так же как ты скинул презентацию. Я лишь говорю, что не стоит пренебрегать EAV если задача сделать на SQL и сделать пиздец динамические типы продукты. Вариант с разреженой таблицей, для пиздец динамических типов продуктов говно - потому что каждый раз нужно выполнять alter table при этом еще думать, что в основную таблицу сунуть, а что в дополнительную. Это должен делать программер. С EAV ты можешь посадить monkey за админку, который будет тебе это вбивать. Вот прежде чем накинуть на вентилятор, перечитай еще раз, чтобы убедится что я только что НЕ говорил "EAV наше все, и только еав потому что так делают другие". Я лишь привел пример того, что это может прекрасно работать и решать свою задачу. Каждый сам решит, стоит ли использовать EAV и для какой задачи. Впрочем, до сюда ты уже не дочитаешь....

дай причину

Тоже стало интересна, какая такая причина, что время на запихнуть везде assert есть, а времени на php7 нету... хм я придумал только одну. Заказчик. Заказчик который говорит "у меня слабость к PHP5 и ни за какие деньги я не отдам свой проект на PHP7" ГЫГЫГЫ

мб у него проект на старом codeigniter/cakephp

т.е. сам фрэймворк придётся обновлять и это потянет за собой изменения в коде

но это гадание

или админ артачится

или все вместе

может стоит начать с приемочных тестов?

хз о чем речь

ну,всё это ниже. про рефакторинг и покрытие тестами т.д. я планирую писать спецификацию, по ней код, а потом покрывать тестами. это BDD вроде называется я пока окончательно не определился как это всё будет выглядеть, но каким боком тут рефакторинг и покрытие тестами я совсем не понимаю

т.е. тестами ведь покрывается уже рабочий код

и не трогается, по-нормальному. а если трогается, то и тесты для него переписываются

писать юнит тесты не так просто как кажется, те которые можно будет поддерживать

наивный )

подозреваю что там бл в контроллерах

вот и предлагают написать приемочные тесты, которые бизнес процессы будут тестировать. оформение заказа, покупку товара

посмотрим как ты юниты на это напишешь )

а потом уже реффакторить

а что там сложно? через phpunit всё делается вход сравнивается с выходом на диапазоне значений

?

я сильно не углублялся, ибо в данный момент typescript'ом занимаюсь. но примерно так я щас это вижу

технически писать не сложно, но это только 10%

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

может стоит начать с приемочных тестов?

для юнит тестов phpunit, для приёмочных и функциональных codeception -- это хороший выбор?

ну,всё это ниже. про рефакторинг и покрытие тестами т.д. я планирую писать спецификацию, по ней код, а потом покрывать тестами. это BDD вроде называется я пока окончательно не определился как это всё будет выглядеть, но каким боком тут рефакторинг и покрытие тестами я совсем не понимаю

это ATDD. BDD это не про тесты. Это как гибрид ATDD + Specification by example

для юнит тестов phpunit, для приёмочных и функциональных codeception -- это хороший выбор?

хз, я приемочные тесты на behat сейчас пишу. Раньше на phpunit. А Codeception - я не нашел его удобным

ого, я думал phpunit только в юнит-тесты может

в codeception примерно также как в behat acceptance тесты

в codeception примерно также как в behat acceptance тесты

а codeception для юнит-тестов можно юзать? просто так много фреймворков, поэтому прошу совета что выбрать. достаточно ли будет одного какого-то фреймворка для всех этих видов тестов(и если да, то какого), или надо будет несколько использовать?

ты бы погуглил на эту тему, ведь там все расписано

http://codeception.com/ на главной странице роликом покрути

ого, я думал phpunit только в юнит-тесты может

потому что у него юнит в названии?)

ну на самом деле фэйл в том что нет четкого определения что такое "юнит тесты". Я использую термин "изолированные тесты", это которые запускаются без зависимостей и все мокается/стабается.

что бы если тест упал - ты очень быстро понимал почему и где сломалось

а не как в случае приемочных тестов - оно то упало но есть сотня причин почему

ну на самом деле фэйл в том что нет четкого определения что такое "юнит тесты". Я использую термин "изолированные тесты", это которые запускаются без зависимостей и все мокается/стабается.

++++

вот я об этом как то говорил но меня называли наркоманом

а codeception для юнит-тестов можно юзать? просто так много фреймворков, поэтому прошу совета что выбрать. достаточно ли будет одного какого-то фреймворка для всех этих видов тестов(и если да, то какого), или надо будет несколько использовать?

а ты точно хочешь юнит тесты (изолированные)? ты уверен что ты будешь их писать? ты уверен что ты умеешь их писать? Ты уверен что у тебя код тестируем? ты понимаешь что юнит тесты не про "тесты" а про дизайн кода?

суть моей мысли в том что люди слишком запутались в том как классифицировать тесты unit, function, acceptance, и тд

вместо того чтобы юзать автотесты как автотесты, а юнит тесты это способ написание АВТОТЕСТОВ в полностью подконтрольном тебе окружение

вместо того чтобы юзать автотесты как автотесты, а юнит тесты это способ написание АВТОТЕСТОВ в полностью подконтрольном тебе окружение

может быть ты запутался?)

может быть вместо того что бы повторять слово "автотесты" 3 раза в одном предложении сконцентрироваться на целях?

Типа более полезные размышления вроде testing vs checking

и тогда все будет проще

из целей у тебя будет вытекать и важность пирамиды тестов

и требуемый уровень изоляции этих тестов

и все такое

@her_ism https://gist.github.com/fesor/db60b4995880925b720be9c7cf75543f

testing и checking это правильно

ребят

ты кидал статью

импортирую таблицу в бд и получаю вот такое

#1215 - Невозможно добавить ограничения внешнего ключа

testing и checking это правильно

что именно правильно?)))

как обойти ?

ты просто привел оба слова, где тут правильно?)

что именно правильно?)))

ты статью кидал на эту тему

что надо разделять

да и как любит говорить @mkusher "правильно" и "не правильно" не инженерные понятия

тесты и проверки

что надо разделять

а зачем надо разделять?

еще раз

и какие выводы из этого разделения мы можем сделать?

к чему нам больше стоит стремиться - к testing или к checking?

авто тест это инструмент чтобы повторять действия которые проверяют что работает твое приложение (код, сайт, библиотека)

это инструмент

авто тест это инструмент чтобы повторять действия которые проверяют что работает твое приложение (код, сайт, библиотека)

юни тесты это намного больше чем автотесты.

когда ты эти действия начинаешь делить на виды уже странно

приемочные тесты построенные на базе каких-нибудь критерий приемки вроде gherkin - это тоже больше чем тесты

типо в этом виде я контролирую окружение тут нет

тут тестирую все целиком

существуют критерии что приложение работает

когда ты эти действия начинаешь делить на виды уже странно

не странно - разные цели

и существует проверка этих критериев которая сделана в виде тестов

какой то критерий надо проверять на полностью поднятом приложение

существуют критерии что приложение работает

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

какой то критерий можно изолированно проверить

короч

кто то пишет не огромное приложение а небольшую библиотеку

останови поток сознания

он не несет ничего полезного в данной дискуссии(

а ты точно хочешь юнит тесты (изолированные)? ты уверен что ты будешь их писать? ты уверен что ты умеешь их писать? Ты уверен что у тебя код тестируем? ты понимаешь что юнит тесты не про "тесты" а про дизайн кода?

когда я выбирал IDE, я не умел её использовать. когда я выбирал язык программирования, я также не умел программировать на нём. понимаешь о чём я?

это не поток сознания

это ты называешь потоком сознания

когда я выбирал IDE, я не умел её использовать. когда я выбирал язык программирования, я также не умел программировать на нём. понимаешь о чём я?

почитай заметку что я скинул

я хочу сначала понять что для чего юзать. субъективно, конечно, ну а как иначе

спасибо, почитаю

но там вряд ли будет ответ)

а ты точно хочешь юнит тесты (изолированные)? ты уверен что ты будешь их писать? ты уверен что ты умеешь их писать? Ты уверен что у тебя код тестируем? ты понимаешь что юнит тесты не про "тесты" а про дизайн кода?

даже более точно про контроль сайд эффектов

я хочу сначала понять что для чего юзать. субъективно, конечно, ну а как иначе

неправильно - сначала цели/идеи а потом инструменты. А так твое представление об этих целях и идеях будет сильно искажено

когда не знаешь что такое сайд эффект ты их делаешь и юнит тестах их потом сложно контролить

ты понимаешь что код неудобно тестить

когда не знаешь что такое сайд эффект ты их делаешь и юнит тестах их потом сложно контролить

блин чел, ты все в такую кашу смешал

не пугай людей

#1215 - Невозможно добавить ограничения внешнего ключа

Читай что такое foreign keys. Тема не маленькая, и простого ответа на твой вопрос нету. Возможно тебе нужно правильный вариант контроля целостности, возможно тебе вообще ключи не нужны. Конкретно эта ошибка говорит что ты пытаешься сослаться на id другой таблицы, хотя в этой другой таблицы сущности с этим id пока что нет. Нужно сначала добавить эту самую связываемую сущность, а затем уже основную.

в моей заметке вопрос сайд эффектов это "второй уровень тестов"

то есть легко