Foundry с 0. Часть 34
Разбирая темы написания тестов с использованием различных паттернов, сервисов и сторонних программ, я пришел к выводу, что, в целом, алгоритм действий очень похож.
Сначала вы определяете для себя, на каких сетях хотите проводить тесты своего протокола, затем описываете набор сторонних контрактов и сервисов, и в завершении все это подключаете в свои тесты через setUp() и скрипты.
В прошлом посте был небольшой пример работы с оракулами Chainlink, и хочу сказать, что с DeFi платформами примерно тоже самое: нашли контракт, подключили, сделали форк и проводите тесты.
Кстати сказать, что компания Immunefi ранее в 2023 выпустила прекрасный набор POC-шаблонов, в которых вы можете подсмотреть как писать тесты для:
1. Флешзайма с Uniswap (V2 и V3), Aave, Balancer, Euler;
2. Манипуляции ценой с использованием dex платформ;
3. Реентранси;
Ссылка на их репо: https://github.com/immunefi-team/forge-poc-templates/tree/main
Даже если не использовать их шаблоны напрямую, можно подсмотреть, как это реализовано и постараться сделать у себя также или лучше.
С мостами дела обстоят несколько сложнее, так как некоторые расчеты происходят вне сети (оффчейн). В тестах за оффчейн операции часто отвечает javascript, а в остальном написание ничем не отличается от уже пройденных нами.
Вы можете сами убедиться в этом, прочитав эту статьи с примерами по тестам мостов:
1. Setting Up A Bridge With Foundry
https://medium.com/immunefi/setting-up-a-bridge-with-foundry-c0d807a3998
Вообще, насколько я понял, самое трудное при работе с проектом, на котором уже были написаны много тестов, это разобраться в архитектуре и понять замысел разработчиков.
Из своего опыта знаю, что на разбор контрактов помощников (Handler, Helper, Utils) действующего проекта, может уйти столько же времени, как и на аудит хорошего контракта.
Кстати, замечал не раз, что у разработчиков есть привычка называть функцию теста тем, что он тестирует (это определенно правильно), но нет привычки писать комментарии к служебным функция в тестах. Например, они сделали настройку определенного состояния контракта на момент теста, но забыли описать, зачем это было сделано. И при том, что тест будет пройден, уязвимость в самом коде остается.
В общем, делайте как можно больше комментариев к своим тестам, служебным функциям и состояниям контракта на момент теста.
#foundry #lesson34
Разбирая темы написания тестов с использованием различных паттернов, сервисов и сторонних программ, я пришел к выводу, что, в целом, алгоритм действий очень похож.
Сначала вы определяете для себя, на каких сетях хотите проводить тесты своего протокола, затем описываете набор сторонних контрактов и сервисов, и в завершении все это подключаете в свои тесты через setUp() и скрипты.
В прошлом посте был небольшой пример работы с оракулами Chainlink, и хочу сказать, что с DeFi платформами примерно тоже самое: нашли контракт, подключили, сделали форк и проводите тесты.
Кстати сказать, что компания Immunefi ранее в 2023 выпустила прекрасный набор POC-шаблонов, в которых вы можете подсмотреть как писать тесты для:
1. Флешзайма с Uniswap (V2 и V3), Aave, Balancer, Euler;
2. Манипуляции ценой с использованием dex платформ;
3. Реентранси;
Ссылка на их репо: https://github.com/immunefi-team/forge-poc-templates/tree/main
Даже если не использовать их шаблоны напрямую, можно подсмотреть, как это реализовано и постараться сделать у себя также или лучше.
С мостами дела обстоят несколько сложнее, так как некоторые расчеты происходят вне сети (оффчейн). В тестах за оффчейн операции часто отвечает javascript, а в остальном написание ничем не отличается от уже пройденных нами.
Вы можете сами убедиться в этом, прочитав эту статьи с примерами по тестам мостов:
1. Setting Up A Bridge With Foundry
https://medium.com/immunefi/setting-up-a-bridge-with-foundry-c0d807a3998
Вообще, насколько я понял, самое трудное при работе с проектом, на котором уже были написаны много тестов, это разобраться в архитектуре и понять замысел разработчиков.
Из своего опыта знаю, что на разбор контрактов помощников (Handler, Helper, Utils) действующего проекта, может уйти столько же времени, как и на аудит хорошего контракта.
Кстати, замечал не раз, что у разработчиков есть привычка называть функцию теста тем, что он тестирует (это определенно правильно), но нет привычки писать комментарии к служебным функция в тестах. Например, они сделали настройку определенного состояния контракта на момент теста, но забыли описать, зачем это было сделано. И при том, что тест будет пройден, уязвимость в самом коде остается.
В общем, делайте как можно больше комментариев к своим тестам, служебным функциям и состояниям контракта на момент теста.
#foundry #lesson34