Replies: 1 comment
-
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
Beta Was this translation helpful? Give feedback.
-
Select Topic Area
Question
Body
While using copilot to generate golang tests, I often find myself wishing I could preempt it to either generate tests for private elements within the package (whitebox) or public elements (blackbox). The generated code I most often receive back appears to prefer public tests, even when the functions within the file are clearly private and not accessible from other packages. I find myself having to rework a lot of the generated code when looking to build tests for internal elements. Not sure if this is something someone is considering as a golang feature in copilot.
It would be awesome if there were two independent menu items "Generate Tests (Blackbox)" and "Generate Tests (Whitebox)", where the first would generate tests of the Public elements using a package with "_test" added it it and maybe the file with the suffix "_blackbox_test.go". While the seconds form would generate tests within the existing package and maybe populated into a file with the suffix "_whitebox_test.go".
The dream would be when asking copilot to generated tests, if there were both public and private elements in the source file, that it generated two _test.go files, one testing the public elements and the other the private elements.
This would greatly speed up efforts generating comprehensive test of both internal and external interfaces of a package and make it easier to identify what form of tests existed in the file(s).
If this functionality already exists in some form please point me at how I can use it, otherwise consider this a feature request.
Beta Was this translation helpful? Give feedback.
All reactions