doza_andВ gcc вставляется специальный дефайн перед stdio.h, таким образом в stdio.h всё заменяется на другие имена, разрешающие 64-битные переменные для всяких внутренних буферов и тому подобного. Но fseek() всё равно по стандарту принимает long int для прыжка. И прыжок от SEEK_CUR тоже что-то не пашет, если его раздробить на блоки.
На сишке наверное.
Основная проблема возникла с моками, надо было сделать юнит-тест, в котором подменить fopen() на пустышку. Так вот оказалось, что моки сделали в Google, с чем явно не хочется связываться, и там же другая платформа для юнит-тестов, гораздо хуже сделанная, чем классическая CUnit. И ещё для этих моков нужно уродовать сам код, похоже, чтобы они могли подменять функции в коде. Бросил эту затею, сделал вместо мока псевдофайл, хотя в питоне такое обычно не требуется - подменил функцию open() и потом просто в этом моке читаешь, что там “писалось” в файл.
FishHookОт юнит-тестов не уйдёшь всё равно. Когда программа вырастает, ты уже не помнишь даже сам, где у неё что внутри, поэтому все эти проверки ложатся на юнит-тесты, которые ты когда-то там, даже не помнишь когда, написал и бросил на месте. Это вот когда один работаешь, а когда над проектом работает несколько человек, незнакомых ни с программой, ни друг с другом (кто-то уволился, кто-то пришёл, потом уволился, потом другой пришёл), то у них нет времени изучать что-то там, тем более готовые части, иначе так можно изучать до бесконечности. Поэтому ты юнит-тесты написал и забыл. Они подключаются ко всей системе и потом прогоняются, прицепленные к общей сборке. Там ещё встаёт вопрос, а все ли тесты написаны. Но это достигается путём инструментов для определения покрытия. Сишные юнит-тесты по покрытию определяются через программку gcov, которая строит граф потока выполнения и показывает, сколько раз по какому оператору кода проход был. Ну в питоне тоже такой инструмент есть - coverage, этот прямо в html-виде может показывать покрытие.
Ну и нахрена нужна была бы такая мощь, наличие которой обязывает к стопроцентному покрытию юнит-тестами?
FishHookВ серьёзных компаниях такие вещи тестируются. Таких попапов сотни, как их все проверить руками? Тебе пользователь написал, например, что такой-то попап не показывается, ты как поймёшь, в чём причина, если эта штука связана с другой, а та - с третьей? Отстутствие тестов выливается в серьёзные затраты по времени. Я вот, бывает, пишу юнит-тест и не могу понять, почему он падает (юнит-тест правильный, но не проходит), открываю gdb и пошёл по вызовам функций (благо там можно брейки прямо на вызовы ставить), так вот времени на это уходит предостаточно, потому что где ошибка - непонятно, а происходить она может в любом месте на любом уровне. Недавно вот аргументы функции передавал не в том порядке, из-за чего всё работало, но работало неправильно и поведение такое странное было, что вообще была непонятно, в каком месте причина. В gdb определил, увидел наглядно, что оно не туда идёт и не то инкрементирует, но время-то ушло. И так на каждую шпуньку будешь тратить по полчаса - это всё в недели сложится.
Ну вот есть у меня на клиенте контроллер, который обрабатывает событие клика на иконке и показывает попап. Что я тут должен тестировать?
FishHookПонятие это плавающее
C++ - язык со слабой типизацией
http://progopedia.ru/typing/strong/
Где-то пишут, что неявных приведений вообще быть не должно, где-то пишут, что могут и быть они, но должны вызывать ошибку, если неправильно что-то. А на python.org вообще пишут, что питон имеет строгую типизацию.
python.org. typing