Какие юнит тесты можно написать для метода — не отсыкайте к теории просто накидайте тестов.

Метод:
decimal GetBalance(int accountId) ??

Здравствуйте, Аноним, Вы писали:

А>Какие юнит тесты можно написать для метода — не отсыкайте к теории просто накидайте тестов.

А>Метод:
А>decimal GetBalance(int accountId) ??

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

Реализации нет. Все что есть — вышеназванный интерфейс. я даже не знаю какие експешены кидаются и является ли -1 валидным номером или нет. Номеров экаунтов нет, а даже если были бы — был ли бы это валидный юнит тест? Я правильно понял что просто вызвать метод для известно-валидный экаунт айдиз?

Здравствуйте, Аноним, Вы писали:


А>Реализации нет. Все что есть — вышеназванный интерфейс. я даже не знаю какие експешены кидаются и является ли -1 валидным номером или нет. Номеров экаунтов нет, а даже если были бы — был ли бы это валидный юнит тест? Я правильно понял что просто вызвать метод для известно-валидный экаунт айдиз?

Как вы себе представляете тестирование чего-либо, что даже неизвестно как работает? Если нет спецификации, то результат "10" будет ли правильным для входного параметра "25"?
Что именно предлагается потестировать в таком разе? Это что, какая-то лабораторная работа? Или квест?

это запрос от американских коллег. нужно написать тесть of the service behavior by knowing its ineterface. я тоже не совсем понимаю как писать юнит тесты для таких задач в принципе. нам нужно привязывать ресультаты к базе данных? наопример счет 5 — бланс 10, а счет 20 баланс -8. Или что? Хорошый тест должне тестировать поведение а не имплементацию. Можно что то раскрутить от этого?

Здравствуйте, Аноним, Вы писали:

А>это запрос от американских коллег. нужно написать тесть of the service behavior by knowing its ineterface. я тоже не совсем понимаю как писать юнит тесты для таких задач в принципе. нам нужно привязывать ресультаты к базе данных? наопример счет 5 — бланс 10, а счет 20 баланс -8. Или что? Хорошый тест должне тестировать поведение а не имплементацию. Можно что то раскрутить от этого?

Давайте уж вы внимательно прочтёте для начала Howtoask. А потом приведёте дословно то, что же вас просят сделать. В том, что вы по-английски процитировали ни слова про юнит-тест нет.

***

I beg your pardon, won't happen no more.


Вот то что надо: Write a unit test to test the behaviour of the *** method.

Здравствуйте, Аноним, Вы писали:

А>Вот то что надо: Write a unit test to test the behaviour of the *** method.

Похоже, это что-то вроде удалённого собеседования

Или давайте сюда контакты вашего рабюотодателя [] или спросите его о спецификации на данный метод. Если спеки нет и не может по каким-то причинам быть, то стратегия такая:
* Включаем соображалку, запасаемся шапочкой из фольги и кофейной гущей и пытаемся представить себе, как должен работать метод. Если говорить о методе из стартового сообщения, то не имеется ли там в виду какая-то конкретная база данных? Не может ли быть так, что GetBalance — просто селектит одно единственное поле из БД без всяких расчётов?
* Включаем холодный рассудок — может баланс быть нулевым? А отрицательным? Может. Есть ли среди значений типа decimal такой, который не может быть значением баланса? Кажется, нет. Значит, если метод запросили с невалидным (например, отсутствующим в БД) номером экаунта, метод должен бросить исключение — у метода нет другого [разумного] способа оповестить внешний мир о том, что метод не смог сосчитать баланс.

На этом месте предлагается стапятидесятиграммировать и выдумать ещё что-либо интересное. Но уже самостоятельно.

Здравствуйте, _FRED_, Вы писали:

_FR>Как вы себе представляете тестирование чего-либо, что даже неизвестно как работает? Если нет спецификации, то результат "10" будет ли правильным для входного параметра "25"?
_FR>Что именно предлагается потестировать в таком разе? Это что, какая-то лабораторная работа? Или квест?

Кстати, на сайте PEX как раз есть такие квесты-загадки: надо при помощи результатов юнит-тестов воспроизвести реализацию загаданного метода

А>decimal GetBalance(int accountId) ??

1) AccountID = 0, 1, -1, MaxInt, MaxInt — 1, MinInt, MinInt + 1.
2) Дважды вызвать GetBalance, результаты должны совпадать.
3) Создать account, в котором balance = 0, MaxDecimal, MinDecimal и проверить что вызов GetBalance возвращает именно это значение.
4) Создать 10 потоков, в каждом из которых вызывать GetBalance для одного и того же accountId, для random accountId.
5) Вызывать GetBalance для последовательно увеличивающихся accountId и для последовательно уменьшающихся accountId.

Здравствуйте, Аноним, Вы писали:

А>Метод:
А>decimal GetBalance(int accountId) ??

Метод сам по себе тестировать нельзя — в любом случае будет создан экземпляр объекта. Этому объекту надо подсунуть базу-заглушку с несколькими известными аккаунтами и убедиться, что метод возвращает заранее известные значения, что возвращает то что надо для несуществующих ID, что не имеет побочных эффектов.

Здравствуйте, abibok, Вы писали:

А>>decimal GetBalance(int accountId) ??

A>1) AccountID = 0, 1, -1, MaxInt, MaxInt — 1, MinInt, MinInt + 1.
A>2) Дважды вызвать GetBalance, результаты должны совпадать.
A>3) Создать account, в котором balance = 0, MaxDecimal, MinDecimal и проверить что вызов GetBalance возвращает именно это значение.
A>4) Создать 10 потоков, в каждом из которых вызывать GetBalance для одного и того же accountId, для random accountId.

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

A>5) Вызывать GetBalance для последовательно увеличивающихся accountId и для последовательно уменьшающихся accountId.

Вот этот пункт непонятен. В чём специфика такой проверки?

Здравствуйте, Аноним, Вы писали:

А>это запрос от американских коллег. нужно написать тесть of the service behavior by knowing its ineterface. я тоже не совсем понимаю как писать юнит тесты для таких задач в принципе. нам нужно привязывать ресультаты к базе данных? наопример счет 5 — бланс 10, а счет 20 баланс -8. Или что? Хорошый тест должне тестировать поведение а не имплементацию. Можно что то раскрутить от этого?

В такой постановке — лучше сдаться сразу.

Здравствуйте, abibok, Вы писали:

А>>decimal GetBalance(int accountId) ??

A>1) AccountID = 0, 1, -1, MaxInt, MaxInt — 1, MinInt, MinInt + 1.
не совсем понятно что тут тестируется

A>2) Дважды вызвать GetBalance, результаты должны совпадать.
не факт. пусть баланс функция от времени (почему нет? и такое бывает)

A>3) Создать account, в котором balance = 0, MaxDecimal, MinDecimal и проверить что вызов GetBalance возвращает именно это значение.
тоже не факт. балансы разные бывают. может, там транзакции пендятся. типа нам бабло зачисляют, но все никак не зачислят, то GetBalance его вернет. так же в тут же созданном акке может быть списане таньги за его создание (почему не может? очень даже может) или поклажа бонусов на счет.

вы уверены, что есть функция SetBalance? вот это точно бред. функция создать акк -- может быть. функция положить бабло -- тоже. функция списать бабло, вычислить проценты -- да. но прямой доступ к балансу на запись -- откуда он?

A>5) Вызывать GetBalance для последовательно увеличивающихся accountId и для последовательно уменьшающихся accountId.
и что это даст?

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

A>>1) AccountID = 0, 1, -1, MaxInt, MaxInt — 1, MinInt, MinInt + 1.
М>не совсем понятно что тут тестируется

Это типичный boundary check для параметра типа int, значения на которых вероятнее всего получить баг.

A>>2) Дважды вызвать GetBalance, результаты должны совпадать.
М>не факт. пусть баланс функция от времени (почему нет? и такое бывает)

Мы не имеем никаких сведений о внутреннем устройстве функции, поэтому не будем усложнять. Считаем что за короткое время между двумя последовательными вызовами состояние системы не изменяется. Вообще эти тесты — не production quality code, а скорее набор идей, которые первыми приходят в голову. В реальных условиях этот набор может быть дополнен/изменен/уточнен. А пока наша цель застолбить основные направления тестирования.

A>>3) Создать account, в котором balance = 0, MaxDecimal, MinDecimal и проверить что вызов GetBalance возвращает именно это значение.
М>тоже не факт. балансы разные бывают. может, там транзакции пендятся. типа нам бабло зачисляют, но все никак не зачислят, то GetBalance его вернет. так же в тут же созданном акке может быть списане таньги за его создание (почему не может? очень даже может) или поклажа бонусов на счет.

Если мы создаем тестовый account, то мы же и контролируем его поведение. Тестирование на живой системе — это уже не unit tests.

М>вы уверены, что есть функция SetBalance? вот это точно бред. функция создать акк -- может быть. функция положить бабло -- тоже. функция списать бабло, вычислить проценты -- да. но прямой доступ к балансу на запись -- откуда он?

В реальном API скорее всего нет. Но для того чтобы продукт хорошо поддавался тестированию в нем или должены быть testability hooks (например какой-нибудь внутренний, доступный только в специальном private билде API) или мы будем использовать mock object. Если в реальной системе код работы с аккаунтом невозможно протестировать, то эта система smells и срочно требует к себе внимания.

A>>5) Вызывать GetBalance для последовательно увеличивающихся accountId и для последовательно уменьшающихся accountId.
М>и что это даст?

Это уже включилось внутреннее чутье задницей, например что аккаунты хранятся в односвязном списке с дорогим доступом. И получение следующего элемента существенно отличается от получения предыдущего элемента. Здесь могут водиться баги. Ну и для самоуспокоения этим тестом (в дополнение к предыдущим) мы получаем полное покрытие операций выборки: заданный элемент, случайный элемент, первый элемент, последний элемент, следующий элемент и предыдущий элемент.

Вот еще пара идей:
6) Замерить среднее время (на большом количестве повторений) выполнения GetBalance. Проверить, что оно не превышает заданного порога.
7) Выполнить GetBalance в контексте разных пользователей. Возможно Bob имеет право доступа к данным, а Alice — нет.

Здравствуйте, abibok, Вы писали:

Да вы, батенька, затейник.

	Скрытый текст
	Наверное, все женщины должны завидовать вашей супруге.

Здравствуйте, abibok, Вы писали:

A>>>2) Дважды вызвать GetBalance, результаты должны совпадать.
М>>не факт. пусть баланс функция от времени (почему нет? и такое бывает)

A>Мы не имеем никаких сведений о внутреннем устройстве функции, поэтому не будем усложнять.
A>Считаем что за короткое время между двумя последовательными вызовами состояние системы не изменяется.

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


A>>>3) Создать account, в котором balance = 0, MaxDecimal, MinDecimal и проверить что вызов GetBalance возвращает именно это значение.
М>>тоже не факт. балансы разные бывают. может, там транзакции пендятся. типа нам бабло зачисляют, но все никак не зачислят, то GetBalance его вернет. так же в тут же созданном акке может быть списане таньги за его создание (почему не может? очень даже может) или поклажа бонусов на счет.

A>Если мы создаем тестовый account, то мы же и контролируем его поведение. Тестирование на живой системе — это уже не unit tests.
согласен, что контролируем, но не согласен, что мы знаем поведение функции по ее имени.


М>>вы уверены, что есть функция SetBalance? вот это точно бред. функция создать акк -- может быть. функция положить бабло -- тоже. функция списать бабло, вычислить проценты -- да. но прямой доступ к балансу на запись -- откуда он?

A>В реальном API скорее всего нет. Но для того чтобы продукт хорошо поддавался тестированию в нем или должены быть testability hooks (например какой-нибудь внутренний, доступный только в специальном private билде API) или мы будем использовать mock object. Если в реальной системе код работы с аккаунтом невозможно протестировать, то эта система smells и срочно требует к себе внимания.

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

Здравствуйте, Кодёнок, Вы писали:

А>>Метод:
А>>decimal GetBalance(int accountId) ??

Кё>Метод сам по себе тестировать нельзя — в любом случае будет создан экземпляр объекта.
Ну в некоторых языках есть так нелюбимые мной свободные функции. Поэтому дословно с Вами не соглашусь.
Но по смыслу очень согласен.
Для юнит тестирования нужно сначала определить границы этого самого юнита.
И это не всегда кстати возможно.
Вот представим, что внутри данной функции производится коннект к захардкоженой реальной продакшиновой базе и запрос туда.
Конечно ситуация почти нереальная но бывают очень похожие ситуации.
И повидав их я очень подозрительно выслушиваю заявления типа "Ведь просили же только прочесть из базы. Я сейчас за пол часа сделаю, а ты со своей архитектурой и тестами неделю будешь возиться!"

Кё>Этому объекту надо подсунуть базу-заглушку с несколькими известными аккаунтами и убедиться, что метод возвращает заранее известные значения, что возвращает то что надо для несуществующих ID, что не имеет побочных эффектов.
Один из вариантов.
Иногда даже удается протестировать отдельно бизнес логику и отдельно синхронизацию доменной модели и базы.
Так получается не всегда, но если получается то тесты очень быстро выполняются(а это иногда критично)

Кё>Метод сам по себе тестировать нельзя

Статический метод — можно.

А>Какие юнит тесты можно написать для метода — не отсыкайте к теории просто накидайте тестов.

А>Метод:
А>decimal GetBalance(int accountId) ??

Жесть конечно.

Если пробовать с BDD-like тестирование, то пишутся тест-методы типа
@Test
public void should<summary of requirement>() {
...
}

В вашем случае требований нет, и их придётся либо достать, либо придумать. Например, такие:

— shouldReturnAccountCurrentBalance
— shouldThrowExceptionIfAccountIdNegative
— shouldThrowExceptionIfAccountNotFound
— shouldThrowExceptionIfAccountClosed

реализовать эти тесты тоже по-нормальному не получится, т.к. имплементации нет, моки не подложить и т.д.
Но в целом получится ответ по вопросу — предположения и сигнатуры тестов в ответ на недосказанность и сигнатуру метода. Клин клином, так сказать.