это интеграционный тест

ими негативные сценарии особо не покрывают

только если очень надо

Хм

ну то есть

юнит тесты = быстрые тесты

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

интеграционные тесты - медленные

e2e тесты - самые медленные, сквозное тестирование системы

что бы тесты приносили больше пользы они должны отрабатывать быстрее

потом много юнит тестов, немножко позитивных интеграционных и если хочется QA могут писать e2e

@laravel_pr из описания чана выпилите

это ж юнит тесты, ими надо покрывать юниты полностью

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

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

так я и не тебе отвечал

пардон

Есть апи, зппрос что-то добавляет в бд. Респонс json с статусом. Как правильно описать негативный тест?

смотри, что есть негативный тест кейс. Например мы посылаем заведомо неверный запрос и все ломается. Или еще чего. Ну то есть как не крути позитивный сценарий покрывает больше кода.

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

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

и тестируешь отдельно

позитивные, негативные сценарии... все

вопервых это будет быстро, а во вторых код станет чуть понятнее

юнит тесты прекрасный механизм декомпозиции на юниты)

У меня вышло, что негативных больше, банально пытался проверить разные варианты. Типа неправильный параметр запроса, ответ...

негативных всегда будет больше

https://www.youtube.com/watch?v=VDfX44fZoMc

хорошее видео на эту тему

Негативные сценарии встречаются как правило на границах слоев

Спасибо

Внутри слоя в основном все по делу, т.е. про бизнес, а не про дефенсив программинг

Парни, ща будет вопрос, который не совсем про ООП...

В общем, есть у меня таблица категорий, каждая категория имеет одного родителя и N дочерних категорий. Так вот - нужно ли использовать one-to-many связь при таком раскладе?

По идее достаточно указать каждой категории единсвенного parent.

(который может быть null)

по идее да)

но мне интересно, даст ли какие-то преимущества otm связь

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

Разве что non-intrusive - если пропала необходимость хранить отношения между категориями, то достаточно удалить эту одну таблицу со связями, не трогая остальных.

хотя не, чет бред несу)

кто разбирается в координатах?

@Golodnyi конкретизируй

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

географические в смысле?

надо перевести в формат яндекса, щя гляну в чем хранит, ну наверно в градусах, минутах и секундах

да

вроде WGS84

да

только что нашел)

latitude/longitude to wgs84 <- вот тут надо искать, мне думается

не, у меня как я понял "минуты дуги"

мне их надо в wgs84

lat: 32251502 lon:52239047 вот что я имею

http://gis.stackexchange.com/questions/56833/wgs84-how-to-convert

это уже на WGS84 похоже

а, нет

похоже, но не является, у меня тут в примерах 33422389 = 55 42,2389 где первая часть мой формат, вторая часть градусы

http://tagis.dep.wv.gov/convert/ тут вот какой-то непонятный конвертер

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

а чатика картографов никто не знает?)

:(

я просто даже не уверен что это минуты дуги, в описании цитата "угол широты в десятичных долях минуты"

хм

если прямо понимать, то

и два пример lat 33422389 = 55 42.2389 lon 22616063 = 37 41.6063

33422389 = 3342238.9 минут

55703.98 градусов

ERROR: S client not available

не, вздор какой-то

вот тока первые 1 цифры и сходятся)

десятичная доля минуты, это ведь остаток?

по идее да

ну типа 33422389 в минутах это 334223890...

думаю да

334223890/60 = 5570398.16667

55 42.2389 не очень похоже на 55 70.0398

ага

головняк

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

да, как-то не особо понятно

че накостылял, получил данные с погрешностью в 63км примерно ^_^

что по сибирским меркам фигня, но для навигации чет перебор)

Ох уж эти обсуждения ооп :)

Всех с пятницей!

Здравствуйте

У вас есть время поговорить о Transaction Script, Table Module, и Domain Model?

Хотелось бы чтобы знающие люди оценили мое понимание...

вещай

попробуй мне например объяснить что есть Table Module

ну или что есть Domain Model и какое отношение Transaction Script имеет к этому добру например

ну короч вещай)

самый простой наверное способ убедиться в том что твое понимание верное - попробовать объяснить другому

На ооп легко программировать чем на php простой?

ООП это методология программирования, а php это язык программирования. Вопрос не понятен

На ооп легко программировать чем на php простой?

проще всего на json-e

что лучше json или rest

из той же оперы

проще всего на json-e

Можете по подробнее объяснить

Можете по подробнее объяснить

по подробнее объяснили уже

ООП это методология программирования, а php это язык программирования. Вопрос не понятен

тут