Принимает ли развитие, основанное на тестировании, дизайн? [закрыто]

Question

Принимает ли развитие, основанное на тестировании, дизайн? [закрыто]

В Java все переменные, которые вы объявляете, на самом деле являются «ссылками» на объекты (или примитивы), а не самими объектами.

При попытке выполнить один метод объекта , ссылка просит живой объект выполнить этот метод. Но если ссылка ссылается на NULL (ничего, нуль, void, nada), то нет способа, которым метод будет выполнен. Тогда runtime сообщит вам об этом, выбросив исключение NullPointerException.

Ваша ссылка «указывает» на нуль, таким образом, «Null -> Pointer».

Объект живет в памяти виртуальной машины пространство и единственный способ доступа к нему - использовать ссылки this. Возьмем этот пример:

public class Some {
    private int id;
    public int getId(){
        return this.id;
    }
    public setId( int newId ) {
        this.id = newId;
    }
}

И в другом месте вашего кода:

Some reference = new Some();    // Point to a new object of type Some()
Some otherReference = null;     // Initiallly this points to NULL

reference.setId( 1 );           // Execute setId method, now private var id is 1

System.out.println( reference.getId() ); // Prints 1 to the console

otherReference = reference      // Now they both point to the only object.

reference = null;               // "reference" now point to null.

// But "otherReference" still point to the "real" object so this print 1 too...
System.out.println( otherReference.getId() );

// Guess what will happen
System.out.println( reference.getId() ); // :S Throws NullPointerException because "reference" is pointing to NULL remember...

Это важно знать - когда больше нет ссылок на объект (в пример выше, когда reference и otherReference оба указывают на null), тогда объект «недоступен». Мы не можем работать с ним, поэтому этот объект готов к сбору мусора, и в какой-то момент VM освободит память, используемую этим объектом, и выделит другую.

24

agile tdd architecture

задан Daniel 17 September 2008 в 05:20

9 ответов

Другие вопросы по тегам:

agile tdd architecture

Похожие вопросы:

score 44 · Answer 1

Нет.

При правильной организации, Разработка через тестирование ЯВЛЯЕТСЯ Вашим средством проектирования.

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

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

TDD рассматривали как задачу, когда его нужно было рассматривать как подход. [...]

был отказ распознать, что TDD не о тестах, itвЂ™s о дизайне. Необузданный случай одноэлементного злоупотребления в модульных тестах сделал это очевидным: вместо тестовых писателей, думающих, вЂњWTF - они одиночный элемент = значение; операторы, делающие в моих тестах? вЂќ, тестовые писатели просто распространили одиночный элемент в тесты. 330 раз.

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

Разработка через тестирование, сделанная правильно, должна сделать разработчиков, высоко знающих о ловушках дизайна как плотное соединение, нарушения DRY (не повторяйте себя), нарушения SRP (Единственный Принцип Ответственности), и т.д.

, Если Вы пишете передающий код для своих тестов ради того, чтобы проходить Ваши тесты, Вы уже перестали работать: необходимо рассматривать трудно для записи тесты как указатели, которые заставляют Вас спросить: почему это сделано этот путь? Почему я не могу протестировать этот код без в зависимости от некоторого другого кода? Почему я не могу снова использовать этот код? Почему этот код повреждается, когда используется отдельно?

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

Кортежи также возвращаются некоторыми объектами коллекции, любят, перечисляют (), где знание кортежей полезно — Murphy, 1 April 2016 в 20:34

score 4 · Answer 2

Я полностью согласен с pjz. Нет никакого правильного способа разработать программное обеспечение. Если Вы доводите до крайности TDD без предусмотрительности кроме следующего модульного теста, можно сделать вещи тяжелее на себе. Так же для человека, который отправляется на главном проекте программного обеспечения путем пребывания в течение месяцев на схемы и документацию, но никакой код.

Умеренный. , Если чувство желание составить быструю схему, которая помогает Вам визуализировать структуру своего кода, пойдите для него. При необходимости в двух страницах могло бы быть пора начать писать некоторый код. И если Вы хотите сделать это перед записью тестов, итак, что. Цель работает, качественное программное обеспечение, не абсолютное соответствие какой-то конкретной доктрине разработки программного обеспечения. Сделайте что работы для Вас и Вашей команды. Найдите области, где улучшения могут быть сделаны. Выполнить итерации.

Я никогда не думал об использовании их как ключи словаря. Хорошая идея. — crystalattice, 19 October 2008 в 06:15

score 3 · Answer 3

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

Jim Coplien сделал доклады по точно этой теме некоторое время теперь:

Недавние исследования (Siniaalto и Abrahamsson) TDD показывают, что он не может обладать никакими преимуществами по традиционной последней из теста разработке и который в некоторых случаях ухудшил код и что он имеет другую аварийную сигнализацию (их слово) эффекты. Тот, который волнует меня большинство, - то, что оно ухудшает архитектуру. - блог

Jim Там также обсуждение, законченное на InfoQ между Robert C. Martin и James Coplien, где они затрагивают этот предмет.

Спасибо за совместное использование - я продолжал редактировать файлы ядра в ~/.ipython после получения некоторых ошибок, но ничто, казалось, не помогло, пока Ваше сообщение не показало мне, что они на самом деле загружаются из ~/Library/Jupyter. Почему находится тот каталог под ~/.ipython даже создан? — Chris, 21 September 2015 в 13:41

score 3 · Answer 4

Мой способ думать об этом, запишите то, на что Вы хотите, чтобы Ваш код был похож сначала. Как только у Вас есть образец Вашего целевого кода (который прямо сейчас ничего не делает), видят, можно ли поместить тестовые леса на него. Если Вы не можете сделать этого, фигура, почему Вы не можете. Большую часть времени это - потому что Вы сделали плохое проектное решение (99%), однако если это не так (1%) пробуют следующее:

определяют то, что сумасшедшие требования - то, что необходимо пребывать к той привычке, которой позволяют Вы протестировать Ваш код. Один Вы понимаете, что проблемы перепроектируют Ваш API.
, если кто-то еще решил это, требования обсуждают об этом его. У них, вероятно, было серьезное основание для требования и как только Вы знаете их причину, Вы будете в состоянии усовершенствовать свой дизайн и сделать его тестируемым. Если не теперь можно и переделать требование, и Вы оба будете лучше для него.

После того, как у Вас есть свой целевой код и тестовые леса. Реализуйте код. Теперь Вы даже имеете преимущество знания, как хорошо Ваше развитие, поскольку Вы проходите свой собственный тест (Большой фактор мотивации!)

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

Если это не работает, см. также 7kemZmani' s ответ. — gc5, 24 February 2017 в 13:52

score 1 · Answer 5

Это всегда - баланс:
- слишком много TDD и Вы заканчиваете с кодом, который работает, но является болью, чтобы продолжить работать.
- слишком много 'maintable кода, уберите дизайн и архитектуру звука', и Вы заканчиваете с Астронавты Архитектуры , которые уговорили себя на кодирование паралича

Модерирование во всех вещах.

Я могу подтвердить, что, если Вы удаляете содержание из указанного местоположения и перезапускаете Ваш ноутбук, это работает. — , 7 August 2016 в 15:13

score 2 · Answer 6

Существует три шага для завершения программного обеспечения:

Делают, это работать
Делает его, право
Делает его быстро

, Тесты получают Вас № 1. Ваш код не сделан просто, потому что тесты передали. Предпочтительно у Вас есть некоторое понятие структуры проекта (Утилиты, обычно получал доступ к объектам, слоям, платформе), прежде чем Вы начнете писать свои тесты/код. После записи кода для создания тестовой передачи, необходимо переоценить его для наблюдения, какие части могут быть пересмотрены к различным аспектам приложения. Yuo может сделать это уверенно, потому что Вы знаете, что, пока Ваши тесты являются все еще передающими, Вы кодируете, все еще функционально (или по крайней мере соответствие требованиям).

В начале проекта, задумайтесь над структурой. В то время как проект продолжается, продолжают оценивать и переоценивать Ваш код, чтобы удержать дизайн на месте или изменить дизайн, если это прекращает иметь смысл. Все эти объекты должны быть приняты во внимание, когда Вы оцените, или Вы закончите с кодом спагетти, TDD или нет.

рекомендуемый! это работало на установку r ядра, даже когда полное переустанавливает анаконду, удаление варева, r и rstudio не работало. — scottlittle, 11 May 2017 в 21:48

score 1 · Answer 7

Я относительно плохо знаком с TDD и поблочным тестированием, но в этих двух параллельных проектах я использовал его на, я нашел, что он помощник дизайна , а не альтернатива дизайну. Способность протестировать и проверить компоненты / субкомпоненты независимо облегчила для меня вносить быстрые изменения и испытывать новые дизайнерские идеи.

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

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

В дополнение к удалению я должен был выполнить следующую команду: ENVS=$(conda env list | grep '^\w' | cut -d' ' -f1);for env in $ENVS; do conda activate $env; python -m ipykernel install --user --name $env; echo "$env"; conda deactivate; done — rraadd88, 18 April 2019 в 13:26

score 1 · Answer 8

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

Однако часть более алгоритмической работы я заключил контракт на, в последнее время пострадал немного под TDD без осторожного баланса мысли дизайна. Оператор выше о более безопасном рефакторинге был все еще большим преимуществом, но для некоторых алгоритмов TDD (хотя все еще полезен) не достаточный для получения Вас к идеальному решению. Возьмите сортировку в качестве простого примера. TDD мог легко привести Вас к субоптимальному алгоритму (N^2) (и ставриды того, чтобы проходить тесты, которые позволяют Вам осуществлять рефакторинг к быстрой сортировке) как пузырьковая сортировка. TDD является инструментом, очень хороший инструмент, но как много вещей должен использоваться соответственно для контекста решаемой проблемы.

У меня есть и python2 и python3, но выше команды doesn' t показывают python3 в jupyter. — DJ_Stuffy_K, 31 January 2018 в 00:25

score 13 · Answer 9

Всегда существует риск того, чтобы переусердствовать или дизайн TDD или первичный дизайн. Таким образом, ответ - то, что это зависит. Я предпочитаю запускаться с пользовательской истории/приемочного испытания, которая является основой требования, чтобы мои тесты помогли в создании. Только после того, как я установил, что, начинаю писать подробный стиль TDD модульных тестов. Если единственный дизайн и размышление Вас делают через TDD, то Вы рискуете слишком большим восходящего подхода, который мог бы дать Вам единицы и классы, которые превосходны в изоляции, но когда Вы пытаетесь интегрировать их в пользовательскую историю, выполняющую задачу, Вы могли бы быть удивлены тем, что сделали все это неправильно. Для большего вдохновения на этом посмотрите внимание BDD.

А большие "дебаты" об этом были зарегистрированы между Robert C. Martin и James Coplien, где первый - защитник TDD, и последний заявил, что это разрушает дизайн системы. Это - то, что Robert сказал о TDD и дизайне:

"Было чувство в Гибком сообществе с тех пор о '99, что архитектура не важна, мы не должны делать архитектуры, все, что мы должны сделать, записать много тестов и сделать много историй и сделать, быстрые повторения и код соберут себя волшебно, и это всегда было дерьмом лошади. Я даже думаю, что большинство исходных Гибких сторонников согласилось бы, что это было глупостью".

James Coplien заявляет, что просто управление Вашим дизайном от TDD имеет большой риск:

"Одна из вещей мы видим много в большом количестве проектов, то, что проекты идут на юг приблизительно на их 3-м спринте, и они отказывают и горят, потому что они не могут пойти дальше, потому что они загнали себя в угол архитектурно. И Вы не можете осуществить рефакторинг свой выход из этого, потому что рефакторинг должен быть через категории класса через иерархии классов, и у Вас больше не может быть обеспечений о наличии той же функциональности".

Также он дает яркий пример того, как банковский счет, вероятно, посмотрел бы, если Вы тестируете, управлял им по сравнению с использованием Вашего первичного знания для управления архитектурой:

"Я помню, когда я говорил с Кентом однажды, о в первые годы, когда он предлагал TDD, и это было в смысле YAGNI и выполнения самой простой вещи, которая могла возможно работать, и он говорит: 'Хорошо. Давайте сделаем банковский счет, сберегательный счет'. Что такое сберегательный счет? Это - число, и можно добавить к числу, и можно вычесть из числа. Таким образом, то, какова учетная запись сохранения, является калькулятором. Давайте сделаем калькулятор, и мы можем показать, что можно добавить к балансу и вычесть из баланса. Это - самая простая вещь, которая могла возможно работать, все остальное - эволюция этого.

, Если Вы делаете реальную банковскую систему, сберегательный счет даже не является объектом, и Вы не собираетесь осуществлять рефакторинг свой путь к правильной архитектуре от той. Какой сберегательный счет, процесс, который делает повторение по журналу аудита транзакций базы данных, депозитов и интересует сборы и другие сдвиги денег. Это не похоже на сберегательный счет, немного денег, находящихся на полке на берегу где-нибудь, даже при том, что это - пользовательская перспектива, и Вы только что узнали это существуют эти относительно сложные структуры в основах банковской системы для поддержки налоговых людей и актуариев и всех этих других людей, до которых Вы не можете добраться возрастающим способом. Ну, Вы можете из-за курса, банковское дело прибыло в это после 40 лет. Вы хотите дать себе 40 лет? Это не является гибким".

интересная вещь здесь состоит в том, что и сторонник TDD и антагонист TDD говорят, что Вы должны разработать впереди.

, Если у Вас есть время, посмотрите ролик. Это - большое обсуждение между двумя очень влиятельными экспертами, и это только 22 минуты длиной.

что я использую для возврата нескольких значений — Ridhwaan Shakeel, 12 March 2019 в 00:50