@Psiman62 We don't have specific guidance documented at the moment. The basic strategy follows what we have in our samples: use the distributed machinery in production (e.g., use the "Send" that the distributed actor framework provides), but erase it all away for testing (e.g., use the Coyote Send instead).
We have some experience doing this with Service Fabric Actors, but it was on an internal codebase. @bchavez is putting together a solution with Orleans Actors that can be a useful guide as it comes together. The "serverless" aspect of Durable Function is perhaps new, so I would be interested in following your progress. And happy to answer questions, of course, as you go along.
I'm a little confused by that, if you are treating coyote tests as some form of unit tests where you are faking the boundaries between your system and an IO system how are you ever going to find any locking issues.
For example if I was using files to save and loading information into my application and there was alocking issue in that particular part of my code but then in my coyote tests I replace actual file system with a fake that just talks to in memory file system how would it ever find the locking?
Deadlock detected. Task(0) is waiting for a task to complete, but no other controlled tasks are enabled.coyote error. And when I debug it seems to be thrown when calling a static method which does almost nothing (the clone method here )
Unhandled exception 'System.IO.FileNotFoundException' was thrown in 'ImageGalleryTests': Could not load file or assembly 'Microsoft.Extensions.Logging.Abstractions, Version=22.214.171.124, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.which leads me to believe that something needs to be updated in the coyote-samples repo