It just sound like a lot of work, but it isnt. If you have fire and forget async methods in the property, you can't control what they are doing. You don't know if there are started or finished or whatever... If you have somewhere code that depends on the result of your fire and forget code, then you will looking for bugs that you will never find. If your fire and forget code is just updating visual stuff (like icons or colors...) then well go for it... If other logic depends on it... Don't do it. Well actually you can do it, if you a fan of bugs. Debugging is a fun hobby. More fun if you are debugging asyncronous code. On top of that... Fire and forget code is very hard (most of the time impossible) to unit test.

It is mostly done in the SearchCommand... Which is triggered if the user hits the enter key or if a small amount of grace period has passed.

No it is not implied... He is just assigning a non started Task to user. As long as he doesnt await user() or user.Result... Then nothing ever happens with it.

Oh no... That Result there is making a sync method out of the async method. And Result shouldn't be used like that... You are asking for deadlocks that way.

Moq is also good.

It is not a good idea because it is fire-and-forget. Unit-testing this kind of code is a pain or plainly not possible. But yes you can do it... Just be aware of the bad stuff that may happen.