Foundry с 0. Часть 15
В завершении этой недели практики с Foundry стоит поговорить об организации файлов при написании тестов. Вы ведь сами понимаете, что "пихать" все тесты в один файл это не только глупо, но и трудночитаемо.
Попробуем представить, какие тесты нам могут потребоваться для нашего проекта:
1. Простые тесты, которые проверят работу функций;
2. Фаззинг тесты;
3. Инвариант тесты;
4. Форк тесты;
5. Интеграционные тесты, когда мы проверяем, что наш протокол правильно взаимодействует со сторонними контрактами, типа Uniswap или Chainlink;
Более того, нам, возможно, нужно будет проверить работу протокола с токенами и другими шаблонами, ну, и не стоит забывать про какие-нибудь хелперы или библиотеки, которые мы можем написать исключительно для наших тестов.
В целом, наша папка test может получиться такой:
test
|-- differential
|-- fork
|-- fuzzing
|-- integartion
|-- invariant
|-- mocks
|-- scenario
|-- unit
|-- utils
|- simple tests
В mocks хранятся шаблоны токенов и других контрактов, которые мы хотим развернуть для тестов, в scenario - сценарии логических тестов, в unit - тесты для условий и порождения событий, в utils - хелперы и библиотеки.
Это самый полный список папок и тестов, который мне удалось найти и собрать вместе. Также не стоит забывать, что было бы хорошо создать подробный readme.md файл или другую документацию с описанием тестов для последующей работы разработчиков и аудиторов.
Я бы также рекомендовал бы добавить сюда отдельную папку hacks, в которую помещать все poc тесты после аудита.
Как вы можете заметить, написание тестов занимает практически столько же времени, сколько и написание самих контрактов, если не больше. Это очень кропотливая работа, на грани с полноценным аудитом.
Надеюсь, этот пост поможет вам лучше составлять архитектуру своих тестов и проверять свой проект вдоль и поперек.
#foundry #lesson15
В завершении этой недели практики с Foundry стоит поговорить об организации файлов при написании тестов. Вы ведь сами понимаете, что "пихать" все тесты в один файл это не только глупо, но и трудночитаемо.
Попробуем представить, какие тесты нам могут потребоваться для нашего проекта:
1. Простые тесты, которые проверят работу функций;
2. Фаззинг тесты;
3. Инвариант тесты;
4. Форк тесты;
5. Интеграционные тесты, когда мы проверяем, что наш протокол правильно взаимодействует со сторонними контрактами, типа Uniswap или Chainlink;
Более того, нам, возможно, нужно будет проверить работу протокола с токенами и другими шаблонами, ну, и не стоит забывать про какие-нибудь хелперы или библиотеки, которые мы можем написать исключительно для наших тестов.
В целом, наша папка test может получиться такой:
test
|-- differential
|-- fork
|-- fuzzing
|-- integartion
|-- invariant
|-- mocks
|-- scenario
|-- unit
|-- utils
|- simple tests
В mocks хранятся шаблоны токенов и других контрактов, которые мы хотим развернуть для тестов, в scenario - сценарии логических тестов, в unit - тесты для условий и порождения событий, в utils - хелперы и библиотеки.
Это самый полный список папок и тестов, который мне удалось найти и собрать вместе. Также не стоит забывать, что было бы хорошо создать подробный readme.md файл или другую документацию с описанием тестов для последующей работы разработчиков и аудиторов.
Я бы также рекомендовал бы добавить сюда отдельную папку hacks, в которую помещать все poc тесты после аудита.
Как вы можете заметить, написание тестов занимает практически столько же времени, сколько и написание самих контрактов, если не больше. Это очень кропотливая работа, на грани с полноценным аудитом.
Надеюсь, этот пост поможет вам лучше составлять архитектуру своих тестов и проверять свой проект вдоль и поперек.
#foundry #lesson15