There are some changes necessary to have better stack traces for because “t.Run” calls the test function from another location. We are in the process of upstreaming them.
Would appreciate your feedback on the style and extension. Would be also interesting to hear other approaches and conventions that could help others to write better tests.
Indeed it is larger but that would be the case no matter the testing style. It just depends on what one wants to check. In our case, it is also a sign for code/api to be refactored if the logic becomes too big (vs simple inputs/outputs).
One problem that often comes up for us is that with “complex objects” we cannot simple use the fields directly unless there is a constructor function. So we often write the initialization right before the “validate” call. How do you currently test code that has complex objects? (e.g. need multiple method calls to setup.)
We are using this style for years now and we found two scenarios to be extremely common:
The “validation” calls are sequential without grouping because the code is simple
The “validation” calls are grouped by categories and subcategories e.g. for our extension we group them into “Go” and “Java” test cases and subcategories for test styles and different errors.
Thank you, that is great to hear If you have any requests or found a bug please let us know. We are currently working on getting our unit test generation (tests WITH inputs and outputs) on par with our Java support. So you can either use a generated test or write a manual one. Would be interested on what you think Tutorial - Symflower CLI
If you have any requests or found a bug please let us know. We are currently working on getting our unit test generation (tests WITH inputs and outputs) on par with our Java support. So you can either use a generated test or write a manual one. Would be interested on what you think