It is amazing for typing out mock data. Say you're testing parsing of XML - it can easily suggest the the assertions over the data parsed from the XML. Example test that was 95% coming out of Copilot: https://github.com/dotnet/arcade-services/blob/61babf31dc63c...

It also predicts comments and logging messages amazingly well (you type "logger." add 7/10 times get what you want, sometimes even better), incorporating variables from the context around. This speeds up the tedious parts of programming when you are finalizing the code (adding docs + tracing).

Honestly, Copilot saves me so much time every week while turning chores into a really fun time.

I honestly thought I'd never use copilot, but when I need to write something to interface with XML via a SOAP API, boy copilot is my best friend...

That code is wretched... Why have serializer logic embedded in a data object, especially when .NET provides generic discrete serializers?

Yeah, tabnine kills it at the data entry parts of test dev as well for sure.

I wrote up some notes on a recent experience I had writing tests with Copilot here: https://til.simonwillison.net/gpt3/writing-test-with-copilot

Once you get the hang of how to prompt it (mainly through clever use of comments) it can be a HUGE time saver.

Yes, if you show an example, or even have the test file open, it will make the other tests for you.

I wonder if this says something about the nature of test code?

Test are always mostly boilerplate and rarely include anything crafty.

95% of tests are: instantiating a class, running a method, and then asserting that the result. Tests do not or should not be crafty creative code snippets. They are boring functional code blocks by design and most are very similar, only changing out inputs and assertions between tests.

I'd go so far as to say if your test is doing something crafty, you're doing tests wrong. Maybe in a mock or fixture, but that's a write-once sort of affair.

I also don't apply DRY (don't repeat yourself) to tests. Tests should be independently readable beginning to end, no context needed. After all, the true value of a unit test is to take a block of code too complicated to easily fit in your mind, and break it down into a series of examples simple enough to fit.

Sure, it's been loads of boilerplate since forever.

Tests often have tons and tons of boilerplate

The best part about it for me is just the Intellisense (in Typescript). I'm using it on probably 3/5 lines that I write as a smarter version, but I rarely use it to do more than finish the current line I am writing.