Tests naming convention
- Alessandro Domanico
- David B Malkovsky
- Emerson Castaneda
Status | In progress |
|---|---|
Impact | High / Medium / Low |
Driver | @Alessandro Domanico |
Approver | @Alessandro Domanico |
Contributors | @David B Malkovsky @Tomasz Tokarczyk @Emerson Castaneda |
Informed |
|
Due date | |
Outcome |
Background
As per discussions here and here, we think it is necessary to spend a few words on which convention is the best to use for method names in this project, bearing in mind that there is not “The” best way and at the moment, we can continue with the general convention that was adopted historically, that is to use the test pattern test<MethodName> or sometimes testIo<MethodName> (to indicate ‘service’ classes), or a more generallytest<PackageAbbreviation><MethodName>.
After many and very important code developments, we have now these other patterns “living” on the code:
Api:
test<MethodName>_<ResponseCode>when_Condition<s>_then_DataResultOrException_ResponseCodeMessage
Core:
test<MethodName>testIo<MethodName>test_<Method>_<SomeModality>test_<SomeOtherModality>_<Method>_<SomeModality>testIo<MethodName>Should<expected>When<condition>test<Model>Getsandtest<Model>Setstest<Model><SomeOtherMethod>testMgr<MethodName>
Gui (WIP: OP-226 and subtasks):
should<expected>When<condition>
Courtesy
So as everybody can see, we have already many different “styles”. This was mostly due to a lack of guidelines.
For sure, since we have many PRs already open under OP-147 (subtasks), in order to avoid slowing down developments, we can opt for the easiest and more homogeneous solution and refactor at a later time.
Options for Methods Naming
| Option1: standard names | Option2: talking names | Option3: snake case |
|---|---|---|---|
Description |
|
|
|
Pros and Cons | easy and direct: not using other terms than test methods strict and uniform: it’s a set of precise rules cannot differenciate different tests over the same method
| it helps with reading test code and enforces proper tests structure it fosters a Test Driven Development approach does not contain the name of the tested Method | it is readable even for quite long test name
|
Options for Structure
| Option1 | Option2 | Option3 |
|---|---|---|---|
Description |
|
| Having a test class per method |
Pros and Cons | Test protected methods without Java reflection Smaller test files No need to prefix tests Coverage readability | It solves problem of too big test class and also helps with creating methods with package private accessor | it makes it clear what the class purpose is and limits class size it might be too fine grained for OH, it end up with lot of files |
Options for Data
| Option1 | Option2 |
|---|---|---|
Description |
| TBD |
Pros and Cons | it increases tests completeness and reliability TBD |
|
Other Proposals/Conventions:
If the purpose of an assert isn't clear then use the "as()" fluent method to define a specific message associated with the test
As 90%+ of the data creation methods call a method like
_setup<TestModel>(boolean usingSet)passing "false" as parameter, just define a propotype_setup<TestModel>()passing false under the hoodto define a way to generate multiple different values for items within each object and then when defining data observations specify the number of observations to setup.
adding
//given:,//when:and//then:comments it helps a lot with reading test code and enforces proper tests structure
Outcome
Open Hospital powered by ISF
2005 - 2016 ISF © Informatici senza frontiere - ONLUS