выхваченные моменты, а не

-----

Я уже как-то спрашивал тебя об том где и как тебя учили географии.

Потрудись ознакомится с тем какие страны есть в Европе и где они находятся...

ну а так вообще, если самоанализ провести, как думаешь, почему тебя не берут ?

правлю резюме от ошибок и добавляю себе опыта до 20 или 21 года. Немецкий и так учу постоянно, как и программирую. Показать заинтересованность в работодателе. Ну и глупые вопросы не задавать.

Вопрос по юнит тестам. Конкретно по NUnit, но вообще любые подходят. Значения типа ExpectedValue, ExpectedResult и прочие подобные (в разных фреймворках по-разному называются) обычно высчитываются "руками" и подставляются как уже рассчитанные числа? Это ваще нормально? Везде где не посмотрю примеры - просто забиты готовые числа!

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

class CharacterStatTests
{
    CharacterStat _charStat;
    double _baseValue = 10;

    [SetUp]
    public void Setup()
    {
        _charStat = new CharacterStat(_baseValue);
    }

    [TestCase(2, ExpectedResult = 12)]
    [TestCase(-2, ExpectedResult = 8)]
    [TestCase(0, ExpectedResult = 10)]
    [TestCase(10.1, ExpectedResult = 20.1)]
    [TestCase(-20.2, ExpectedResult = -10.2)]
    public double AddModifier_AbsoluteValueModifier_ValueChangesCorrectly(double value)
    {
        _charStat.AddModifier(new StatModifier(value, StatModifierType.Absolute));
        return _charStat.Value;
    }
}

А по идее должно быть

_baseValue

+

value из TestCase

Чтобы руками не считать, а автоматизировать, вижу только вариант убрать ExpectedResult и всё считать внутри тестового метода, и потом делать Assert.AreEqual

[TestCase(2)]
[TestCase(-2)]
[TestCase(0)]
[TestCase(10.1)]
[TestCase(-20.2)]
public void AddModifier_AbsoluteValueModifier_ValueChangesCorrectly(double value)
{
    _charStat.AddModifier(new StatModifier(value, StatModifierType.Absolute));
    var result = _charStat.Value;
    var expected = _baseValue + value;

    Assert.AreEqual(result, expected);
}

Но это не так красиво, как затолкать ExpectedResult в атрибут!

Всё, короче, юнит тесты я освоил. Напишу в резюме NUnit, MSTest. Ули нам, котонам. ))

Ваще, по логике, два значения - по тестируемому коду и проверочное - должны быть рассчитаны независимо и сравнены. Но можно поставлять проверочное значение вбиванием числа, а можно расчётом - второе предпочтительнее, если вдруг другие числа, на основании которых всё рассчитывается (типа моего _baseValue) поменяются. Вбитые руками придётся перебивать, а рассчитанные не придётся.

А так проблема, что логику всё же придётся дублировать в тесте. В коде что-то делается, и та же логика должна быть повторена в тестовом методе - по сути, она должна быть написана дважды. И при изменении логики кода должна поменяться и логика теста или сам тест вообще заменён. Короче, любые изменения - боль. А быстрые изменения в нашем аджайле - основа основ. Вопрос - на..я это всё? Тесты, имею ввиду. При быстрых изменениях логики ты просто пишешь два раза один и тот же по сути код и тестируешь очевидные вещи. Тестирующего кода даже больше получаться может. Вот щас у меня логика, которую я тестирую - 15 строчек кода. А объём тестов будет экрана на 2. Я чёт сути не понимаю.

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

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

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

При этом при любом редизайне (изменении функциональности) ты сначала переписываешь тесты, а потом код. Не наоборот.

А теперь вопрос. Вас кинули на старый проект - починить баг или изменить-дописать-удалить функциональность. Никто уже не знает, кто его писал и как. Где гарантия, что он написан по TDD и вы можете просто поменять тесты, чтобы потом дописать код?

Получается, что...

-----

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

если самоанализ провести

-----

Я как минимум лучше тех, кто ...

Это ваще нормально? Везде где не посмотрю примеры - просто забиты готовые числа!

не только нормально, но и правильно

Т.е. считаем где-то на стороне - в уме, в стороннем калькуляторе. Считать тут же в тестовом классе считается плохо? Почему?

Мне лень считать, я сделал так. Тестовые значения одинаковые для нескольких тестов - их в источник тестовых данных. Ожидаемые значения - рассчитываю - банальное сложение с базовым значением. Эта же логика и в тестируемом коде - сложение с базовым значением. Этим я повторяю логику, которую тестирую в тестируемом коде. Потом сравниваю ожидаемые и полученные в результате работы тестируемого кода.

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

[TestFixture]
class CharacterStatTests
{
    CharacterStat _charStat;
    readonly double _baseValue = 10;

    readonly static double[] _testValues = { 2, -2, 0, 10.1, -20.2 };

    [SetUp]
    public void Setup()
    {
        _charStat = new CharacterStat(_baseValue);
    }

    [TestCaseSource(nameof(_testValues))]
    public void AddModifierTest(double test)
    {
        var result = _charStat.AddModifier(test); // logic being tested
        var expected = _baseValue + test; // here repeat the logic from the logic being tested

        Assert.AreEqual(result, expected);
    }
}

Так можно делать, т.к. здесь банальные рассчёты, типа сложения, вычитания, умножения и деления, которые зависят от языка и фреймворка и которые тестировать не надо (они уже оттестированы). Поэтому на них "можно положиться".

Вот чуваки спорят - хардкодить или не хардкодить.

c# - Should unit test expected results be hardcoded? - Software Engineering Stack Exchange

Мнения разделились - это зависит от...

А у нас прога сама себя тестировала. Программа генерировала рандомный текст, числа, даты, и я точно уже в деталях не помню толи переключались сначало спомощью SetActiveWindow а потом посылали CTRL+V вот так:

keybd_event(VK_LCONTROL, 0, 0, 0);
keybd_event(0x56, 0, 0, 0);
keybd_event(VK_LCONTROL, 0, KEYEVENTF_KEYUP, 0);
keybd_event(0x56, 0, KEYEVENTF_KEYUP, 0);

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

Есть минус, если ожидаемые значения вычисляются без меня - я их не вижу. Может, результаты вычислений аномальные, и это будет видно, если на них взглянуть. Хотя тесты при этом будут проходить.

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

Но как считать-то? В калькуляторе отдельно каждое ожидаемое значение, даже если их тысячи, и копировать потом до последнего знака после запятой, если это скажем double?

Наверное, можно записать один раз действия (мышь и клавиатура), симулируя поведение пользователя, и потом проигрывать их с разными параметрами ввода в поля и нажатия на контролы.

Мне лень считать

-----

Ндааа...

Насчет - подумать - Я уже и не ожидаю...

Этим я повторяю логику

-----

А ты ее знаешь?

Тебе ее кто-то объяснил? Если нет - то - Как? А может кто объяснял сам не понял и там не плюс а минус... да еще с кусочно-непрерывной апроксимацией...

А писать надо сейчас...

банальные рассчёты

-----

А если не банальные?

Вдруг вот прогер уже всю плешь проел математику чтобы тот объяснил что и как и все одно в рассчет "въехать" не может...

А завтра вообще математика сменят и новый считать решит по-другому...

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

Этим я повторяю логику

-----

А ты ее знаешь?

Тебе ее кто-то объяснил? Если нет - то - Как? А может кто объяснял сам не понял и там не плюс а минус... да еще с кусочно-непрерывной апроксимацией...

А писать надо сейчас...

В ТЗ должно быть. Или какой там документ, более подробно описывающий функции программы. Если описания слишком абстрактные, вы нормальные тесты не напишете. Разве что это будет описание целых систем программы и их взаимодействие. Но это уже будут скорее интеграционные тесты.

А если дело касается математики и конкретных формул, то они заранее по ТЗ известны - их что в тестах, что в логике один в один воспроизводите. Я в своей проге выносил все формулы в отдельную сборку (где и другие общие ресурсы были). Из этой сборки можно подключать формулы как к основной бизнес-логике программы, так и к тестам. Просто конкретно в моём примере там и формулы особой нет - простые действия, типа плюс-минус, умножить-разделить.

Вдруг вот прогер уже всю плешь проел математику чтобы тот объяснил что и как и все одно в рассчет "въехать" не может...

А завтра вообще математика сменят и новый считать решит по-другому...

Смена расчёта - это смена тестов этого расчёта. Если надо выдрать этот расчёт - математику - из бизнес-логики, тогда нужно подставить заглушку в это место - моки-шмоки всякие, или предполагаемый набор результатов расчёта. Для условий тестирования можно добавить правильные и неправильные результаты в эту заглушку.

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

Как работу разные люди находят, которые и половины не знают, что знаю я? Хотя, у них с немецким, наверное, неплохо - можно красиво приседать...

Чтобы отвязались со своими "что же вы, под сорокет и не сеньёр-помидор?", можно дуть в уши, что я Quereinsteiger - сменщик карьеры. А почему "дуть"? Я и есть такой - образование не по профилю, уже канает.

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