Создаю видеокурс по созданию "клеточного автомата" на дельфи. Математическая модель общества

[anaschu]

да, и самое главное, что нужно ручками дописать все входные, я какого то фига думал, что тест будет их подтягивать автоматом с уже сделанной проги, но это не так.
Готовая прога будет храниться тут
git@gitlab.com:anaschu/soc_mod_woman_man.git в ветке (возврат для переделки)
В ветке мастер храниться рабочая прога без теста.
Скоро закомпилю видео, где я всё это сделал

Form.Free логал, так как ему нечего было освобождать, похоже

Какие две процедурки я больше всего менял в генерированном коде? вот:

procedure TestTField.TestfillField;
var
  i,j,maxValue: Integer;

begin

  // TODO: Setup method call parameters
  FField.fillField(3, 3, 10);
  // TODO: Validate method results
  Check(((FField.FArea[0,2]<>FField.FArea[1,0]) and (FField.FArea[0,0]<>FField.FArea[0,1]) and (FField.FArea[0,2]<>FField.FArea[0,1]) ), 'данные в клетках однообразны') ;
  for i := 0 to colCount do
    for j := 0 to rowCount do
      begin
        Check( FField.FArea[i,j]>=0,'ресурсы в клетке не существуют' + inttostr(i) + inttostr(j));
      end;


end;

procedure TestTField.SetUp;
begin
  FField := TField.Create(3,3);
  colCount := 3;
  rowCount := 3;
end;

[Alex11223]

Сообщение от anaschu

делать разработку через тестирование, прочитав две инет статьи по 3 страницы, это не очень хорошо

прочитайте третью ) https://ru.hexlet.io/blog/posts/how-to-test-code

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

[anaschu]

Сообщение от Alex11223

Важнее просто писать тесты, чтобы не повторять всё каждый раз вручную

я скорее говорю о unit тестировании. наверное, оно не обязательно входит в TDD

[anaschu]

Сообщение от Alex11223

прочитайте третью ) https://ru.hexlet.io/blog/posts/how-to-test-code

апологеты юнит тестов. мне там показалось важным:

1. функция, которая принимает на вход путь до файла и подстроку для поиска, а на выходе (не печатает на экран!) отдает готовый результат, так, чтобы осталось только напечатать его. Такой вид тестов обладает самым лучшим балансом “убедиться в том что все работает/стоимость”. Они косвенно затрагивают все используемые внутренности, не зависят от реализации, очень просты в написании и крайне дешевы в поддержке. УРОВЕНЬ ТЕСТИРОВАНИЯ ДОЛЖЕН БЫТЬ ТАКОВ, ЧТО БЫ НЕ ЗАКАПЫВАТЬСЯ В АРХИТЕКТУРУ, И НЕ УХОДИТЬ В ИНТЕРФЕЙС

2. ЭТОМУ МАЛОСТЬ ПРОТИВОРЕЧИТ ВОТ ЭТО: при проектировании кода мы начинаем думать не о том, как сейчас клево насоздаем файлов[spoiler] и разнесем по ним функции, создав десятки абстракций- [/spoiler]А НАЧИНАЕМ ДУМАТЬ О ЦЕПОЧКЕ ДЕЙСТВИЙ КЛИЕНТА С ТВОИМ ПРОДУКТОМ, ТО ЕСТЬ ДУМАЕМ О ИНТЕРФЕЙСЕ

3. код, пригодный для модульного тестирования, становится более качественным.


вот эт я не понял:
[spoiler]
1. "Проектирование внешнего api ".
2.https://www.cypress.io/


интеграционные и приёмочные тесты я позырю сильно потом....через годик

там была ссылочка. там - противоположное мнение высказывается

важно:


1. Для многих областей, например для графических интерфейсов, отдача от других видов тестов больше, чем от модульных. клеточный автомат в некотором роде- графический интерфейс
2.три измерения, по которым можно оценить тест:
Стоимость (дешёвый или дорогой)
Скорость (быстрый или медленный)
Уверенность (низкая или высокая, то есть «не работает щелчок мышью» или «не работает оформление заказа») (кубок тестирования)
3. «пирамиды тестирования» Фаулера,
[spoiler]4. Чем больше тесты похожи на то, как используется приложение, тем больше уверенности они могут вам дать
5. Возможно, отдельные части приложения работают, но приложение в целом — нет.
6. Интеграционные тесты лежат где-то посередине между модульными и сквозными, так что они обеспечивают наибольшее равновесие. Такие образом, они обладают наивысшей окупаемостью инвестиций.
7. главное — просто использовать поменьше заглушек.
8. Теперь у вас два новых компонента с разными интерфейсами. Все ваши модульные тесты внезапно утратили смысл.
9. модульные тесты увеличивают затраты на обслуживание, так как они менее устойчивы к изменениям в коде. [/spoiler]

почитать: “Does Test-Driven Development Really Improve Software Design Quality?” [spoiler](«Действительно ли разработка через тестирование повышает качество проектирования ПО?»). В другой статье, “Unit Testing Doesn’t Affect Codebases the Way You Would Think” («Модульное тестирование влияет на кодовые базы не так, как вы думаете»)

[Alex11223]

Сообщение от anaschu

я скорее говорю о unit тестировании

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

В статье идея была в том, что как правило лучше не писать юнит тесты на все мелкие внутренние компоненты, потому что они могут часто меняться, а тестировать что-то более крупное, например какой-то основной результат сложного алгоритма.
При этом с другой стороны тестировать код прибитый к графическому интерфейсу (GUI) сложно, поэтому лучше попробовать сделать какую-то функцию, которая просто принимает данные и возвращает результат (массив, объект, ...), и ее вызывать и в GUI (рисовать что-то на основе возвращенного результата), и в тестах.
Я не знаю что у вас программа делает, так что сложно привести близкий пример. Например, если программа выводит различия между двумя текстовыми файлами (diff), то можно сделать функцию, которая принимает две строки с содержимым файлов и возвращает какую-то структуру (или просто текст с плюсами и минусами в начале строк). И тестировать соответственно эту функцию, а не все подряд мелкие внутренние функции типа сравнения слов, символов.
Или другой пример, в научных работах по сравнению каких-то похожих алгоритмов (например, поиск чего-то) как правило тестируют реализации алгоритмов с каким-то определенными данными (передать датасет, проверить, что вернуло ожидаемые элементы), а не более мелкие функции используемые внутри.

Сообщение от anaschu

ЭТОМУ МАЛОСТЬ ПРОТИВОРЕЧИТ ВОТ ЭТО: при проектировании кода мы начинаем думать не о том, как сейчас клево насоздаем файлов[spoiler] и разнесем по ним функции, создав десятки абстракций- [/spoiler]А НАЧИНАЕМ ДУМАТЬ О ЦЕПОЧКЕ ДЕЙСТВИЙ КЛИЕНТА С ТВОИМ ПРОДУКТОМ, ТО ЕСТЬ ДУМАЕМ О ИНТЕРФЕЙСЕ

там нет такой цитаты, но под интерфейсом там имеется в виду API https://ru.wikipedia.org/wiki/API (например API какой-то математической библиотеки), а не GUI.

Сообщение от anaschu

клеточный автомат в некотором роде- графический интерфейс

наверняка там можно выделить какую-то абстракцию не прибивая всё к GUI.
это не только для тестов может понадобиться.

[anaschu]

https://youtu.be/jM8WFvz7ovE

[anaschu]

Сообщение от Alex11223

можно выделить какую-то абстракцию не прибивая всё к GUI.

пока у меня с этим проблемы. выбираю отдельный юнит, и все равно к GUI всё прибивается, к главному юниту. То есть, по сути, у меня проблема со Stub

[SPOILER]Stub (стаб, заглушка) — это код, которым заменяется некоторый другой код (процедура, функция, класс), от которого зависит тестируемый код. Например, Ваш метод зависит от функции, которая делает HTTP запрос. Стабом будет замена этой функции, на другую, которая возвращает заранее известный результат (и не лезет в сеть).[/SPOILER]

Пока получается брать половину Unitов и тестить их отдельно от всего остального вот так:
https://youtu.be/c7DGBW9dHus

[anaschu]

Сообщение от Alex11223

можно выделить какую-то абстракцию

неудобно, что если я во время постановки заглушки Stub решил, что у меня, скажем, во всех проверках ширина и длинна поля будет равна трем, это надо вводить константами не только сверху юнитов, которые скопированы из проги.
но и внутрь юнита test/
неудобно, что нельзя вводить тесты последовательно. надо либо выбирать сразу все, либо забыть о том, что ты хотел разобраться с какими то "потом".
Дело в том, что их надо перекидывать из publik в published.

И от качества заглушки зависит очень много. Так, многие методы внутри теста не работают. А в программе- работают. и как им доверять? Хотя не! всё норм...оказывается, с помощью теста нашел новые ошибки в проге.
https://youtu.be/qcqiPZdz1_M

[Alex11223]

Я не про заглушки, это вообще отдельное.

Я про создание какого-то внутреннего представления клеточного автомата (или что там у вас), не связанного с UI, на основе которого выводите визуализацию в UI.

[anaschu]

Сообщение от Alex11223

Я не про заглушки, это вообще отдельное.

Я про создание какого-то внутреннего представления клеточного автомата (или что там у вас), не связанного с UI, на основе которого выводите визуализацию в UI.

ну вот сейчас вроде как научился отдельно от GUI делать. я оченб долго собиираюсь не менять количество и взаимоотношение классов в проге, так чё тест юнит варик- как раз про меня!

https://youtu.be/CiwK8JjSbI0

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