Best practices for Branching Tree Technique (BTT) #647
Replies: 2 comments 3 replies
-
Thank you for your recent contributions, @smol-ninja, as well as the detailed write-up. I see two intertwined problems here:
After pondering this topic for a while, my answers are:
Some additional points:
|
Beta Was this translation helpful? Give feedback.
-
Added support for this in |
Beta Was this translation helpful? Give feedback.
-
I have been working on refactoring the test code by following the best practices for Branching Tree Technique (BTT) as explained in the presentation- Testing Best Practices in Foundry by @PaulRBerg. The techniques aim at creating a tree structure that can explain test case scenarios even to a non-technical person. A simple example:
can be represented by the following tree structure.
There are two keywords to specify the states:
When
for function parameters andGiven
for contract states. As in the above example,Null
is a functional parameter condition represented by theWhen
keyword.In a more complicated scenario such as
where
DelegateCalled
is technically not a contract state but a mode of execution, it becomes hard to categorize this intoWhen
andGiven
.If we use
Given
forDelegateCalled
, we can also useRevertGiven
instead ofRevertWhen
for it butRevertWhen
sounds friendlier as a function name whileGiven
can be more appropriate as a modifier's name. (Given this, Revert when)It, thus, can be refactored as the following:
This improves the readability of the tree structure in line with the naming convention used for function names, but brings in inconsistencies in the use of
Given
andWhen
to specify states. Have a look at the below tree structure:The goal of this discussion is to find the best approach for using English keywords to build a tree structure so that it can be automated with the naming conventions of the test functions.
Beta Was this translation helpful? Give feedback.
All reactions