Когда я за компьютером, то все записи веду на нем в цифре. Когда нет — блокнот. Его я всегда ношу с собой вместе с ручкой. Пользоваться телефоном как записной книжкой мне совершенно не нравится, да и никакой адекватной синхронизации все равно для себя не нашел.
Раз в день выгружаю все, что в блокноте накопилось, переношу это в цифровой формат.
В данный момент это работает и меня устраивает, но все равно рано или поздно будет меняться куда-нибудь.
Вот так сразу — нет. Но любой пользователь такого устройства имеет право обратиться к производителю и должен получить в ответ исходники. При этом вполне может быть, что исходники он получит, но также и требование не распространять их (чтобы исходники были только у тех, у кого есть устройство).
В emacs это тоже есть прямо из коробки. Достаточно открыть "файл" вида /ssh:user@server:path/to/file. В случае разрыва связи ничего не поломается, при попытке сохранить емакс сам восстановит соединение.
Там не коллбэки, это в espresso так ассерты выглядят. А проблема заключалась в том, что селекторы onView и onData имеют разное применение, официально рекомендовался именно onData с очень размытым объяснением почему именно он. Но для данного конкретного теста требовался именно onView.
Любое действие, которое помогает проявить ошибку, имеет смысл. "Сломать код, чтобы увидеть, что тест сломался" позволяет проявить ошибку в тесте, если вдруг я ее там допустил. Особенно если сопоставить простоту этого действия с трудностью поиска ошибки, если она действительно допущена.
Равно как я и не рекомендую запускать тесты автоматически при каждом сохранении любого файла. Я это делать буду. А еще я приводил примеры, когда я по собственной невнимательности получал проблемы, когда переставал выполнять описанные выше ритуалы.
Если вы можете писать код и уверены в том, что он правильно работает, даже если не запускаете тесты, рад за вас. Когда я так делаю, то потом трачу больше времени на поиск ошибок. Поэтому стараюсь быть более аккуратным.
Это некоторый утрированный пример. Когда я писал какие-то более сложные штуки на жаве, я действительно сталкивался с ситуацией, что вроде бы вот код, корректно написан, должен проверять то, что требуется. Но только вот не заметил, что тестируемый класс был взят не из того пакета, который нужен.
А по конкретному "тесту" — да, не доверяю, и уже опять же на это нарывался, когда вдруг оказывалось, что тест вообще не подхватился и не был запущен.
Если я заранее знаю, что мне не придется тягать штанги, то и тренироваться не имеет смысла. Если я заранее знаю, что мне не придется писать на питоне быструю сортировку, то нет смысла в сайтах типа codewars.
Это тренировка, в том числе дисциплины. Просто сделать аккуратно. А заодно это немножко почешет мое чувство удовлетворения, когда я сначала увижу красную лампочку, а потом зеленую. В конце концов, я сюда пришел не для того, чтобы тяп-ляп и в продакшн за прибылью.
Это предельный вариант TDD — сначала мы тестируем, что код есть. Тест падает. Пишем заголовок для кода, но не тело. Часть теста проходит, а дальше все равно падает. Пишем захардкоженную константу. И так далее.
Ну… да, TDD в применении к модульному тестированию. Но так или иначе, к тесту, который никогда не падал, у меня доверия особо нету. Если проверку на "ну вот мы сломали, убедились, что тест это обнаружил, вернули на место" провести трудно, придется жить с надеждой на то, что тест действительно существует для того, чтобы что-то обнаруживать. Тест, который ни разу ничего не обнаружил, вызывает подозрения.
Если тест сразу зеленый, то это правда нехорошо. Но необязательно ломать код — можно сломать тест. И убедиться, что "это мне просто так повезло, что я сразу угадал поведение", а не "а этот тест в любом случае зеленый, какую бы чушь я тут ни написал". Впрочем, код я бы тоже попробовал сломать. Мне очень важно убедиться, что код и тест друг другу соответствуют по правильности.
Как уже было сказано выше, это правило, записанное кровью. Я потратил очень много часов, разбираясь с ошибкой, которая не должна была происходить "ведь есть же тест", только из-за того, что тест на самом деле не срабатывал.
Ломание теста или кода нужно для того, чтобы проверить утверждение на тавтологичность. Мы заявили, что все вороны черные. Мы не можем написать тест, который полностью это за нас сделает. Но что если в мире вообще нет ни одного нечерного предмета? Ну такое вот у нас загадочное определение черного цвета. Ломаем тест — требуем, чтобы вороны были красными. На черную ворону тест выдает ошибку. Ок, чиним обратно тест, ломаем код. Теперь на красную ворону тест выдает ошибку. По крайней мере из кода может прийти что-то такое, что тест может различать как правильное или неправильное, а не всегда говорит "ок, йа отработал".
Наконец, можно еще более усилить свой TDD и вообще не иметь кода на момент написания тестов. Тест не сможет пройти, когда кода нет. Ситуации, когда тест сразу зеленый, в таком случае не будет никогда.
Я перешел на раздельную клавиатуру в мае этого года. Постепенно все шире и шире раздвигал половинки и через пару месяцев решил перенести трекбол между половинок. Все равно не очень удобно — получается, что трекбол и правая половина клавиатуры "борются" между собой, чтобы занимать то место, где мне удобнее держать правую руку. Для игр я отодвигаю клавиатуру еще дальше, сдвигая трекбол чуть правее. Для набора текста наоборот, клавиатура лежит симметрично, трекбол ближе к центру. Частично это связано с тем, что у меня и сама клавиатура лежит около края стола, выдвинуть трекбол "ближе" не получается.
Когда я выбирал себе трекбол, для меня главным требованием было наличие отдельного скролла. Трекболы под большой палец вообще не рассматривал. В результате взял Kensington Orbit. Позже добыл себе и Kensington Expert, но из-за большой разницы между высотой стола и стула пользоваться им было неудобно (а нормального кресла у меня тогда дома не было), поэтому его унес на работу, а дома вернулся к обычному Orbit.
Для точности управления я вращаю шары одновременно двумя пальцами — указательный+безымянный. Даже тяжелые шары в результате удается аккуратно позиционировать, потому что один из пальцев разгоняет, а второй тормозит.
Когда я за компьютером, то все записи веду на нем в цифре. Когда нет — блокнот. Его я всегда ношу с собой вместе с ручкой. Пользоваться телефоном как записной книжкой мне совершенно не нравится, да и никакой адекватной синхронизации все равно для себя не нашел.
Раз в день выгружаю все, что в блокноте накопилось, переношу это в цифровой формат.
В данный момент это работает и меня устраивает, но все равно рано или поздно будет меняться куда-нибудь.
Вот так сразу — нет. Но любой пользователь такого устройства имеет право обратиться к производителю и должен получить в ответ исходники. При этом вполне может быть, что исходники он получит, но также и требование не распространять их (чтобы исходники были только у тех, у кого есть устройство).
В emacs это тоже есть прямо из коробки. Достаточно открыть "файл" вида /ssh:user@server:path/to/file. В случае разрыва связи ничего не поломается, при попытке сохранить емакс сам восстановит соединение.
Там не коллбэки, это в espresso так ассерты выглядят. А проблема заключалась в том, что селекторы onView и onData имеют разное применение, официально рекомендовался именно onData с очень размытым объяснением почему именно он. Но для данного конкретного теста требовался именно onView.
Конкретно по ссылке кода нет, код живет тут: https://github.com/aragaer/yama_android/blob/master/src/androidTest/java/com/aragaer/yama/ListActivityTest.java#L237
Замена onView на onData превращает тест во "всегда зеленый".
Внезапно нашел: Не конкретный код, а моя же собственная запись в ЖЖ на эту тему: https://aragaer.livejournal.com/181037.html
К психологу
По поводу причины проблем я хожу к специалисту, спасибо за заботу.
Любое действие, которое помогает проявить ошибку, имеет смысл. "Сломать код, чтобы увидеть, что тест сломался" позволяет проявить ошибку в тесте, если вдруг я ее там допустил. Особенно если сопоставить простоту этого действия с трудностью поиска ошибки, если она действительно допущена.
Равно как я и не рекомендую запускать тесты автоматически при каждом сохранении любого файла. Я это делать буду. А еще я приводил примеры, когда я по собственной невнимательности получал проблемы, когда переставал выполнять описанные выше ритуалы.
Если вы можете писать код и уверены в том, что он правильно работает, даже если не запускаете тесты, рад за вас. Когда я так делаю, то потом трачу больше времени на поиск ошибок. Поэтому стараюсь быть более аккуратным.
Но мне нравится запускать тесты и видеть как что-то происходит. И кроссворды разгадывать тоже нравится.
Это некоторый утрированный пример. Когда я писал какие-то более сложные штуки на жаве, я действительно сталкивался с ситуацией, что вроде бы вот код, корректно написан, должен проверять то, что требуется. Но только вот не заметил, что тестируемый класс был взят не из того пакета, который нужен.
А по конкретному "тесту" — да, не доверяю, и уже опять же на это нарывался, когда вдруг оказывалось, что тест вообще не подхватился и не был запущен.
Это не тест, это некий ассершн.
Вот если бы это было что-то вроде...
Если я заранее знаю, что мне не придется тягать штанги, то и тренироваться не имеет смысла. Если я заранее знаю, что мне не придется писать на питоне быструю сортировку, то нет смысла в сайтах типа codewars.
Это тренировка, в том числе дисциплины. Просто сделать аккуратно. А заодно это немножко почешет мое чувство удовлетворения, когда я сначала увижу красную лампочку, а потом зеленую. В конце концов, я сюда пришел не для того, чтобы тяп-ляп и в продакшн за прибылью.
Это предельный вариант TDD — сначала мы тестируем, что код есть. Тест падает. Пишем заголовок для кода, но не тело. Часть теста проходит, а дальше все равно падает. Пишем захардкоженную константу. И так далее.
http://wiki.c2.com/?TransformationPriorityPremise — иногда я в таком стиле развлекаюсь с кодом.
Ну… да, TDD в применении к модульному тестированию. Но так или иначе, к тесту, который никогда не падал, у меня доверия особо нету. Если проверку на "ну вот мы сломали, убедились, что тест это обнаружил, вернули на место" провести трудно, придется жить с надеждой на то, что тест действительно существует для того, чтобы что-то обнаруживать. Тест, который ни разу ничего не обнаружил, вызывает подозрения.
Если тест сразу зеленый, то это правда нехорошо. Но необязательно ломать код — можно сломать тест. И убедиться, что "это мне просто так повезло, что я сразу угадал поведение", а не "а этот тест в любом случае зеленый, какую бы чушь я тут ни написал". Впрочем, код я бы тоже попробовал сломать. Мне очень важно убедиться, что код и тест друг другу соответствуют по правильности.
Как уже было сказано выше, это правило, записанное кровью. Я потратил очень много часов, разбираясь с ошибкой, которая не должна была происходить "ведь есть же тест", только из-за того, что тест на самом деле не срабатывал.
Ломание теста или кода нужно для того, чтобы проверить утверждение на тавтологичность. Мы заявили, что все вороны черные. Мы не можем написать тест, который полностью это за нас сделает. Но что если в мире вообще нет ни одного нечерного предмета? Ну такое вот у нас загадочное определение черного цвета. Ломаем тест — требуем, чтобы вороны были красными. На черную ворону тест выдает ошибку. Ок, чиним обратно тест, ломаем код. Теперь на красную ворону тест выдает ошибку. По крайней мере из кода может прийти что-то такое, что тест может различать как правильное или неправильное, а не всегда говорит "ок, йа отработал".
Наконец, можно еще более усилить свой TDD и вообще не иметь кода на момент написания тестов. Тест не сможет пройти, когда кода нет. Ситуации, когда тест сразу зеленый, в таком случае не будет никогда.
Я перешел на раздельную клавиатуру в мае этого года. Постепенно все шире и шире раздвигал половинки и через пару месяцев решил перенести трекбол между половинок. Все равно не очень удобно — получается, что трекбол и правая половина клавиатуры "борются" между собой, чтобы занимать то место, где мне удобнее держать правую руку. Для игр я отодвигаю клавиатуру еще дальше, сдвигая трекбол чуть правее. Для набора текста наоборот, клавиатура лежит симметрично, трекбол ближе к центру. Частично это связано с тем, что у меня и сама клавиатура лежит около края стола, выдвинуть трекбол "ближе" не получается.
Когда я выбирал себе трекбол, для меня главным требованием было наличие отдельного скролла. Трекболы под большой палец вообще не рассматривал. В результате взял Kensington Orbit. Позже добыл себе и Kensington Expert, но из-за большой разницы между высотой стола и стула пользоваться им было неудобно (а нормального кресла у меня тогда дома не было), поэтому его унес на работу, а дома вернулся к обычному Orbit.
Для точности управления я вращаю шары одновременно двумя пальцами — указательный+безымянный. Даже тяжелые шары в результате удается аккуратно позиционировать, потому что один из пальцев разгоняет, а второй тормозит.
Теперь сделать такое же для футбола и можно подключать к телевизору.