Open mehanizm opened 4 years ago
Merging #62 into master will increase coverage by
4.62%
. The diff coverage is82.50%
.
@@ Coverage Diff @@
## master #62 +/- ##
==========================================
+ Coverage 73.25% 77.88% +4.62%
==========================================
Files 21 21
Lines 890 850 -40
==========================================
+ Hits 652 662 +10
+ Misses 206 156 -50
Partials 32 32
Impacted Files | Coverage Δ | |
---|---|---|
custom-fields.go | 100.00% <ø> (+83.87%) |
:arrow_up: |
card.go | 59.16% <82.50%> (+1.64%) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update bc8f627...f731393. Read the comment docs.
This PR has three commits that need the review.
feat: add RemoveIDCustomField method
In this commit I've added the method to delete (only clear) custom field of the card by its ID (see "Clearing CustomFieldItems" here).
But there was a problem. Because of the definition of the
Value
field in theCustomFieldItem
result from the API was not parsed correctly. I'd tried to understand why we need here (in general purpose library) so complex unmarshaling with some kind of the business logic and stuck with that. There are no tests to explain this.impr: change custom fields value struct
To develop this idea I've simplified
CustomFieldItem
struct and all corresponding methods. No tests was broken after that, only type actualization.impr: refactor CustomFields method
As a result I've refactor
CustomFields
card method to use more idiomatic go code and new simplifiedCustomFieldItem
struct.Conclusion
I think, that it is more correct style for the general library and type casting from the
CustomFieldItemValue
should be done in the business logic on the application level. The casting logic that was here earlier is hard to understand and did not have general application.