La, c'est parce que la base contient encore (on en a déjà parlé :)) des choses qui sont de nature trop différentes.

Moi, sur le schéma que je vois, c'est le test untaires qui est en bas du triangle et donc sont les plus nombreux (oui, je sais, ça ne tient pas compte de la durée d'exécution)

Là, ça correspond au schéma

Ca serait cool d'avoir un exemple de fixture multiple pour montrer comment ca se passe sur le constructeur

On dirait que tu explique ce qu'est une classe en C# a des débutants. Il serait plus claire de dire qu'une fixture est n'importe quel POCO (et donc on devine qu'il peut avoir un constructeur) et que xUnit honore le IDisposable.

L'expression est un peu floue.

Qu'est-ce que conceptuellement amène à la phrase?

Une instance de la classe de test est construite juste avant l'exécution de chaque méthode de test (vérifié avec [Fact]) puis détruite juste après. EN d'autres termes, chaque méthode de test s'exécute dans une instance spécialement créé pour cette exécution

Créer soit même la classe de fixture dans le constructeur de la classe de test revient donc à créer la fixture autant de fois qu'il y a de méthode de test.

L'avantage avec IClassFixture est que l'instance de fixture est la même pour toutes les méthode de test d'une même class.

AFactoringXunitTestFramework n'est pas déclaré ailleur

A quand les attributs génériques? C'est encore dans la roadmap

Tu va avoir deux raisons d'avoir un paramètre de type InfiniteSquareFixture passé à ton ctor:

1 au travers de la collection et 1 au travers de l'implémentation directe de IClassFixture<InfiniteSquareFixture> Que se passe-t-il dans ce cas? Ca devrait être des instances différentes.

.Net Core 3.0 est cross platforme, c'est juste les packs de compatibilité WinForms et WPF qui sont Windows uniquement. Et ce n'est pas la première fois, Windows Compatibility Pack était déjà Standard 2.0 et CoreApp2.0 et 2.1.

C'est marrant, je voyais plus ça comme "la grande convergence". Un peu dans la droite lignée du fait que .Net Core avait commencé par s'appeler 5.0. 5.0, c'est le successeur de 4.8, non? En fait, si on y réfléchis, c'est un peu comme si MS avait une stratégie depuis le départ et qu'il n'en avait jamais dévié (ce dont je doute mais on peut toujours rêver). Mais effectivement, c'est quand on a convergé que les problèmes de divergences commencent...

Pour l'instant, c'est plus un pre preview. Je pense que ça va arriver avec VS 2019 qui semble imminent. Ça fait plusieurs post que je vois passer qui explique comment modifier les extensions pour qu'elle marchent dès le premier jour (c'est un signe qui ne trompe pas).

Avec pour avantage de permettre une élimination du code non utilisé. Si on est en SCD, ça devrait permettre de ne pas distribuer la totalité de .Net Core 3.0 dans chaque Apps.

Sans vouloir casser l'ambiance, il y a aussi des désavantages. Par exemple, on conserve les limitations de Core: par exemple, plus de AppDomain, plus de TransparentProxy, etc...

Ta phrase donne l'impression qu'il s'agit d'un mode de fonctionnement imposé alors que c'est juste une possibilité.