Ivan Petrov's questions

Digamos que eu tenha um Serviceque tenha uma dependência em TimeProvider.

O que faço agora para configurar o uso do FakeTimeProviderAutoFixture e do Moq para meus testes é:

public class FakeTimeProviderCustomization : ICustomization {
    public void Customize(IFixture fixture) {
        fixture.Customize<TimeProvider>
            (c => c.FromFactory(() => new FakeTimeProvider()));
    }
}

public class MoqAutoDataAttribute : AutoDataAttribute {
    public MoqAutoDataAttribute()
        : base(() => new Fixture()
        .Customize(new AutoMoqCustomization())
        .Customize(new FakeTimeProviderCustomization())
        ) {
    }
}

[Theory, MoqAutoData]
public async Task Test_TimeRelatedStuff(
    [Frozen] TimeProvider timeProvider,
    Service sut) {
    
    ...
    var fakeTimeProvider = timeProvider as FakeTimeProvider;
    ...

Posso evitar o elenco FakeTimeProviderque tenho que fazer toda vez?

Neste vídeo recente de Nick Chapsas, no final ele comentou que o Findmétodo on List<T>era "não otimizado" porque o código não itera no Span do array, mas no próprio array:

public T? Find(Predicate<T> match) {
    if (match == null) {
        ThrowHelper.ThrowArgumentNullException(ExceptionArgument.match);
    }

    for (int i = 0; i < _size; i++) {
        if (match(_items[i])) {
            return _items[i];
        }
    }
    return default;
}

Achei que a iteração em spans poderia ser feita tão rápido quanto em arrays (mas não mais rápido) a partir deste parágrafo da postagem do blog (atualizada?) de Stephen Toub sobre Spans:

O código assembly é tão similar em parte por causa da eliminação de verificações de limites. Mas também é relevante o reconhecimento do JIT do indexador span como um intrínseco, o que significa que o JIT gera código especial para o indexador, em vez de traduzir seu código IL real para assembly.

Tudo isso serve para ilustrar que o tempo de execução pode aplicar aos spans os mesmos tipos de otimizações que aplica aos arrays , tornando os spans um mecanismo eficiente para acessar dados.

Quando se tornou evidente que iterar no Span de um array seria tão rápido e talvez mais rápido do que apenas iterar no próprio array? Qual versão do .NET introduziu essas otimizações de JIT Span que não podiam ser usadas para arrays?

Para o estático, DispatchProxy.Create<T,TProxy>()a documentação nos diz que:

Cria uma instância de objeto que deriva da classe TProxye implementa a interface T.

Ter o seguinte código de teste confirma que:

interface I{
    void Foo();
}

class D : DispatchProxy {
    protected override object Invoke(MethodInfo targetMethod, object[] args) {
        Console.WriteLine("In Invoke");
        return null;
    }
    public virtual void DMethod(){
    }
}

var proxy = DispatchProxy.Create<I,D>();
Console.WriteLine(proxy.GetType().BaseType); // typeof(D)
Console.WriteLine(proxy is I); // true

Então a parte interessante sobre o Invokemétodo de acordo com os documentos :

Sempre que qualquer método no tipo de proxy gerado é chamado, esse método é invocado para despachar o controle.

Isso pode significar

proxy
.GetType()
.GetMethods(BindingFlags.NonPublic|BindingFlags.Public|BindingFlags.Instance|BindingFlags.Static)
.Select(x => x.Name)

o que nos dá

Foo Invoke DMethod GetType MemberwiseClone Finalize ToString É igual a GetHashCode

mas se testarmos se chamamos Invoketanto o método de interface quanto o método de classe de despacho:

proxy.Foo(); // In Invoke
((D)proxy).DMethod(); // nothing

Observando como DispatchProxyo tipo de proxy gerado é implementado com um campo privado com uma matriz de MethodInfos que são usados ​​nos métodos stub com chamadas para Invokeele, fará sentido que só possamos ter esse comportamento com métodos que podemos substituir.

É por isso que defini o DMethod como virtual, mas aparentemente nenhum stub foi criado.

Isso significa que os documentos devem declarar:

Sempre que qualquer método de interface >>> no tipo de proxy gerado é chamado, este método é invocado para despachar o controle.