Для этого проще один раз ударить владельца камнем по голове, приложить палец к сканеру и вырубить защиту по отпечатку или переключить на свой палец.
Да и я сомневаюсь, что кто-то будет таскать на телефоне в не зашифрованном виде информацию, которая стоит заморочек с отрезанным пальцем и насосом.
Ну вернул он true, как и требовалось, но на реальных данных валится.
Значит проблема в реальных данных. Их и проверяйте. Например, взять Rails. Мне не нужно проверять в большинстве случаев, как работает ActiveRecord — это давно проверили за меня разработчики. Поэтому я могу мокнуть нужный мне AR-объект или класс и проверять обращения к нему с возвратом фейковых данных.
Если не эмулировать зависимости, тесты станут очень чувствительными и начнут падать буквально от ошибки в любом методе. Да и вам же самому будет сложнее отловить ошибку. Представьте, что у вас ошибка в некоем методе X, который используется в пяти других методах, которые в свою очередь используются еще в двадцати методах итд. Если не стабить этот метод X в тестах, то при ошибке в нем мы получим груду свалившихся тестов, которые придется разгребать. В случае, когда метод застаблен, ошибка в нем никак не повлияет на тесты остальных методов, и вы получите в лучшем случае один упавший тест, а в худшем — несколько, но указывающих непосредственно на этот метод. Ошибку легко сразу локализовать и исправить.
если ты сервис, то по IP.
а если будет контрольная закупка, то всем пофиг, если у хозяина сайта Российское гражданство Ж-).
Турбик — сервис, отслеживают по IP.
При чем тут гражданство хозяина?
во всех странах: пиратство — вне закона, вопрос в том что по разному преследуется.
В Сомали, например, нет. Да и почему это российские власти должны преследовать кого-то за нарушение чужих законов в чужой стране?
а раздающие сервера точно вне России?
я конечно могу поковырять и найти все данные, но как-то не хочется выкладывать анализ, чтобы им потом кто-нить вредный воспользовался.
1. Плохо написанные тесты. Объем тестов более чем в 2-3 раза превышающий объем кода — это уже подозрительно.
2. Плохо спроектированные тесты. Если изменение кода функции валит тест, не относящийся напрямую к этой функции (не считая приемочных, конечно), то это плохие тесты. Не говоря уже о том, что тест должен быть изменен до изменения функции.
3. Чаще всего не нужно тестировать каждое поле. Если такая необходимость есть, то либо неправильно спроектирован код, либо тесты. Например, мы проверяем форму на корректный вывод ошибок. Большинство полей типовые, пара штук — с особенностями. Если код спроектирован правильно, ошибки, выводимые на форму, берутся из какого-то объекта (модели или form object). В таком случае достаточно протестировать класс этого объекта на предмет выдачи правильных ошибок, одно-два типовых поля формы (одним тестом) и поля с нестандартным поведением.
4. Это не проблема тестов и TDD. Даже если вы не пишите тестов вообще, этот баг все равно может быть в других местах.
5. Опять же не проблема TDD. Просто напишите тест после обнаружения бага.
6(1). Уже отписали выше — либо неудачная архитектура, либо неправильный подход к тестам. Хотя, при приемочных тестах да, приходится иногда много чего сгенерировать.
6(2). Что значит «нужны»? В одной из статей одного из TDD-отцов было сказано примерно следующее: покрывайте код настолько мало, насколько позволяет ваша уверенность. Конечно, слепо следовать этому не стоит, но нужно иметь это ввиду. Например, я никогда не пишу тесты для контроллеров. Я считаю это пустой тратой времени, т.к. эти же случаи можно более наглядно протестировать в приемочных тестах. Я пишу тесты контроллеров только для специфических случаев. Кому-то это покажется неправильным (тут есть свои недостатки, согласен), но я делаю так.
7. И опять это не проблема подхода TDD как такового.
Многие воспринимают тесты как панацею. Мол, напишу я тесты и все будет тип-топ, код станет стабильным, безбажным, красивым и вообще. Это не так. Тесты помогают ускорить дальнейшую работу с кодом. Я трачу 10 минут на написание теста и экономлю часы в будущем для проверки этих же кейсов вручную. Тесты помогают сохранить работоспособность при рефакторинге. Написал функцию, запустил тесты — все в шоколаде, ничего нигде не упало, можно спать спокойно. Тесты помогают продумать архитектуру. Часто после написания тестов я просто создаю класс/функцию и сразу пишу «зеленый» код: все, что мне нужно было придумать и учесть, я придумал и учел во время написания тестов.
Конечно, тут нужна сноровка. В некоторых специфических случаях я трачу немало времени, чтобы написать хороший тест. В дальнейшем для подобных моментов у меня уже будет решение и я буду писать по накатанному пути. Но когда я только начинал, тесты отнимали реально много времени в основном из-за незнания многих принципов. Слава богу, заказчик был не против.
При чем тут домен? Лицензия выдается юр. лицу. А уж через интернет оно будет сериалы показывать или выкатит телевизор на улицу — дело десятое.
А вот вопрос про агрегаторы интересный. Но упертых правопродавателей вряд ли получится убедить в том, что так денег накапает больше, чем посредством запретов.http://habrahabr.ru/post/190940/#refresh
А как тогда определять «гражданство» пользователей? Вот турбик, например, работает не только на Россию, но и на СНГ, да и вообще для любого русскоговорящего пользователя интернета в любой стране. То, что показ сериалов запретили в России, еще не значит, что его запретили везде.
Ну ок, признают турбик незаконным и заблокируют, а дальше что? Через VPN он все равно будет доступен. Сервера не вынесут по причине их отсутствия на территории РФ, домен не разделегируют по той же причине. Турбик распространяется посредством «сарафанного радио», поэтому неудобства с VPN ему не помешают.
Проблема с «в интернете кто-то не прав» присутствует, каюсь. Ок, объясняю. Но последний раз. Надеюсь.
Аудитория одна и та же. В интересах всех производителей продать каждому человеку и мобильник, и планшет, и ноутбук, и компьютер, и приставку (а лучше две). Они не взаимозаменяющие, а взаимодополняющие устройства. Хотя да, те же планшеты могут немного ударить по рынку ноутбуков и т.д.
Эти ваши слова есть ярчайшее подтверждение моих слов. Производителям интересно продать пользователю все типы устройств, а для этого нужно предложить разный набор приложений. Мобильные приложения и мобильные игры-эксклюзивы для мобильников и планшетов, десктопные приложения и ПК игры-эксклюзивы для десктопов, консольные эксклюзивы для консолей. Если бы по факту это все являлось одним типом устройств, маркетологам бы ничего не удалось: нахрена мне планшет, если я на ноутбуке в птиц шпилю неплохо? Нафига мне десктоп, если я на консоли играю в старкрафт? Технически эти устройства могут быть хоть абсолютно идентичны, но пока маркетологи разделяют эти устройства, их рынки будут различны. Это то, что я пытался до вас донести вот уже чуть менее двух суток. Но вы со своим подключением монитора к телефону, никсами на мобильнике и WinRT просто не хотите это понимать.
Яркий пример немного из другой степи — продукция Apple. Они очень ловко отделяют свою продукцию от всей остальной. Есть плееры, а есть iPod. Есть планшетники, а есть iPad. Есть ноутбуки, а есть Macbook. Apple специально создает свою «экосистему», в которой все устройства связаны и прекрасно взаимодействуют. Все для того, чтобы выделить себя в отдельный рынок. Хотя в начинке их устройств нет ничего особенного.
Да и я сомневаюсь, что кто-то будет таскать на телефоне в не зашифрованном виде информацию, которая стоит заморочек с отрезанным пальцем и насосом.
Значит проблема в реальных данных. Их и проверяйте. Например, взять Rails. Мне не нужно проверять в большинстве случаев, как работает ActiveRecord — это давно проверили за меня разработчики. Поэтому я могу мокнуть нужный мне AR-объект или класс и проверять обращения к нему с возвратом фейковых данных.
Если не эмулировать зависимости, тесты станут очень чувствительными и начнут падать буквально от ошибки в любом методе. Да и вам же самому будет сложнее отловить ошибку. Представьте, что у вас ошибка в некоем методе X, который используется в пяти других методах, которые в свою очередь используются еще в двадцати методах итд. Если не стабить этот метод X в тестах, то при ошибке в нем мы получим груду свалившихся тестов, которые придется разгребать. В случае, когда метод застаблен, ошибка в нем никак не повлияет на тесты остальных методов, и вы получите в лучшем случае один упавший тест, а в худшем — несколько, но указывающих непосредственно на этот метод. Ошибку легко сразу локализовать и исправить.
Турбик — сервис, отслеживают по IP.
При чем тут гражданство хозяина?
В Сомали, например, нет. Да и почему это российские власти должны преследовать кого-то за нарушение чужих законов в чужой стране?
В Германии. Можете не утруждать себя.
2. Плохо спроектированные тесты. Если изменение кода функции валит тест, не относящийся напрямую к этой функции (не считая приемочных, конечно), то это плохие тесты. Не говоря уже о том, что тест должен быть изменен до изменения функции.
3. Чаще всего не нужно тестировать каждое поле. Если такая необходимость есть, то либо неправильно спроектирован код, либо тесты. Например, мы проверяем форму на корректный вывод ошибок. Большинство полей типовые, пара штук — с особенностями. Если код спроектирован правильно, ошибки, выводимые на форму, берутся из какого-то объекта (модели или form object). В таком случае достаточно протестировать класс этого объекта на предмет выдачи правильных ошибок, одно-два типовых поля формы (одним тестом) и поля с нестандартным поведением.
4. Это не проблема тестов и TDD. Даже если вы не пишите тестов вообще, этот баг все равно может быть в других местах.
5. Опять же не проблема TDD. Просто напишите тест после обнаружения бага.
6(1). Уже отписали выше — либо неудачная архитектура, либо неправильный подход к тестам. Хотя, при приемочных тестах да, приходится иногда много чего сгенерировать.
6(2). Что значит «нужны»? В одной из статей одного из TDD-отцов было сказано примерно следующее: покрывайте код настолько мало, насколько позволяет ваша уверенность. Конечно, слепо следовать этому не стоит, но нужно иметь это ввиду. Например, я никогда не пишу тесты для контроллеров. Я считаю это пустой тратой времени, т.к. эти же случаи можно более наглядно протестировать в приемочных тестах. Я пишу тесты контроллеров только для специфических случаев. Кому-то это покажется неправильным (тут есть свои недостатки, согласен), но я делаю так.
7. И опять это не проблема подхода TDD как такового.
Многие воспринимают тесты как панацею. Мол, напишу я тесты и все будет тип-топ, код станет стабильным, безбажным, красивым и вообще. Это не так. Тесты помогают ускорить дальнейшую работу с кодом. Я трачу 10 минут на написание теста и экономлю часы в будущем для проверки этих же кейсов вручную. Тесты помогают сохранить работоспособность при рефакторинге. Написал функцию, запустил тесты — все в шоколаде, ничего нигде не упало, можно спать спокойно. Тесты помогают продумать архитектуру. Часто после написания тестов я просто создаю класс/функцию и сразу пишу «зеленый» код: все, что мне нужно было придумать и учесть, я придумал и учел во время написания тестов.
Конечно, тут нужна сноровка. В некоторых специфических случаях я трачу немало времени, чтобы написать хороший тест. В дальнейшем для подобных моментов у меня уже будет решение и я буду писать по накатанному пути. Но когда я только начинал, тесты отнимали реально много времени в основном из-за незнания многих принципов. Слава богу, заказчик был не против.
А вот вопрос про агрегаторы интересный. Но упертых правопродавателей вряд ли получится убедить в том, что так денег накапает больше, чем посредством запретов.http://habrahabr.ru/post/190940/#refresh
Ну ок, признают турбик незаконным и заблокируют, а дальше что? Через VPN он все равно будет доступен. Сервера не вынесут по причине их отсутствия на территории РФ, домен не разделегируют по той же причине. Турбик распространяется посредством «сарафанного радио», поэтому неудобства с VPN ему не помешают.
В этом и корень проблемы. Удачи :)
Эти ваши слова есть ярчайшее подтверждение моих слов. Производителям интересно продать пользователю все типы устройств, а для этого нужно предложить разный набор приложений. Мобильные приложения и мобильные игры-эксклюзивы для мобильников и планшетов, десктопные приложения и ПК игры-эксклюзивы для десктопов, консольные эксклюзивы для консолей. Если бы по факту это все являлось одним типом устройств, маркетологам бы ничего не удалось: нахрена мне планшет, если я на ноутбуке в птиц шпилю неплохо? Нафига мне десктоп, если я на консоли играю в старкрафт? Технически эти устройства могут быть хоть абсолютно идентичны, но пока маркетологи разделяют эти устройства, их рынки будут различны. Это то, что я пытался до вас донести вот уже чуть менее двух суток. Но вы со своим подключением монитора к телефону, никсами на мобильнике и WinRT просто не хотите это понимать.
Яркий пример немного из другой степи — продукция Apple. Они очень ловко отделяют свою продукцию от всей остальной. Есть плееры, а есть iPod. Есть планшетники, а есть iPad. Есть ноутбуки, а есть Macbook. Apple специально создает свою «экосистему», в которой все устройства связаны и прекрасно взаимодействуют. Все для того, чтобы выделить себя в отдельный рынок. Хотя в начинке их устройств нет ничего особенного.