Migration from XUnit is painful.

[kant2002]

Design which requires assert to be awaitable, make migration from XUnit or MSUnit or NUnit painful.

1. All tests now have to be async Task which is.. you know... lot of typing.

2. That looks super strange to compare things in awaitable fashion.

Assert.Equal(new char[] { 'D' }, input.ВисокошвидкосніПрінтери);

vs

await Assert.That(new char[] { 'D' }).IsEqualTo(input.ВисокошвидкосніПрінтери);

3. Same problem but with untyped new.

Assert.Equal(new("PRODUCT-NO", 'A'), input.Перший);
Assert.Equal(new("PRODUCT-NO", 'B'), input.Другий);

become

await Assert.That(new ПосиланняНаПоле("PRODUCT-NO", 'A')).IsEqualTo(input.Перший);
await Assert.That(new ПосиланняНаПоле("PRODUCT-NO", 'B')).IsEqualTo(input.Другий);

notice that I have to write type name.

4. Other small details, is that you cannot use collection initializers in your asserts, thus require rewriting tests again.

Probably only XUnit related.

var input = Assert.IsType<Input>(операція);

become

await Assert.That(операція).IsTypeOf(typeof(Input));
var input = (Input)операція;

5. Cannot compare T and T? for simple types.

Assert.Equal((ushort)10, input.Більше);

become

await Assert.That((ushort?)10).IsEqualTo(input.Більше);

6. Ooh. I just notice. You insist on having specific order of declaration

await Assert.That('A').IsEqualTo(input.ІсходнийФайл);

is invalid, since I have to rewrite like that.

await Assert.That(input.ІсходнийФайл).IsEqualTo('A');

which is understandable, but again. I have to retype a lot of code.

7. I don't know what's going on, but when comparing arrays I cannot use IsEqualsTo and have to use IsEquivalentTo which is not what I expect from other frameworks.
8. When I try to compare array of tuples, it does not work. Nor IsEqualsTo nor IsEquivalentTo works for me.

await Assert.That(input.ОписПереміщення).IsEquivalentTo(new (ПосиланняНаПоле ІсходнеПоле, ПосиланняНаПоле[] ЦільовіПоля)[] {
    (new ПосиланняНаПоле("PRODUCT-NO", 'A'), [new ПосиланняНаПоле("PRODUCT-NO", 'W')]),
    (new ПосиланняНаПоле("QUANTITY", 'A'), [new ПосиланняНаПоле("QUANTITY", 'W')]),
});

Summary

Overall I think migration process even for small set of 13 tests which I have , is very painful to my taste.

[SaschaBa]

Hi,

I really like what I have seen until now from TUnit and would like to convert our XUnit tests to TUnit. I use a lot IsType and Single, which is very helpful, because it returns the result to do further testing with it. I thought about to write own Asserts, but I don't know how to return a value I can use in the next steps. It seems it is not intended to have a result of an Assert. Is this planned for the next time?

Thanks

[thomhurst]

@kant2002 I'm sorry that you have to make changes but it's a different framework so it's expected to have API differences. I didn't set out to copy the xUnit API exactly. So unfortunately it will be a bit of a manual task for now.

It's actually probably possible to create analyzers with code fixes to help automate the process but that will be quite a big task so it would take quite a bit of time and effort to implement.

[thomhurst]

Hi,

I really like what I have seen until now from TUnit and would like to convert our XUnit tests to TUnit. I use a lot IsType and Single, which is very helpful, because it returns the result to do further testing with it. I thought about to write own Asserts, but I don't know how to return a value I can use in the next steps. It seems it is not intended to have a result of an Assert. Is this planned for the next time?

Thanks

Heya. Returning values sounds like it could be useful and doable. Leave this with me !

[kant2002]

@thomhurst I did not expect API match one-2-one, but most other frameworks, at least for smaller projects can be very easiely migrated, since a lot of things converge.

It would be hard sell to migrate to your framework for existing codebases IMO, where benefits would be move prominent. I mean, I wrote this only to give you hint on how painful would be migrate existing tests suites. I bet MsTest would be the same deal.

The more users you could steal from others, the better to shake status quo a bit 😄 .

[Xen0byte]

@kant2002 If it helps at all, when I did this I used a few cycles of regex find and replace and it wasn't incredibly painful.

[kant2002]

@Xen0byte maybe it make sense to share it, even if not for my sake, but for others? What do you think. Even if it’s rough probably still would be better

[Xen0byte]

@kant2002, unfortunately I didn't save them, it was a quick-and-dirty on-the-fly thing, but in hindsight I should have. They're pretty easy to write, it took me about 30 minutes to do an entire solution with about 2.5k tests across multiple projects. The regular expressions would look like something along the lines of the following:

find: Assert.Equal((?<expected>.*), (?<actual>.*));
replace: await Assert.That(${actual}).IsEqualTo(${expected});

NOTE 1: For assertions (example above) I would strongly recommend getting rid of the xUnit assertions library reference before you do this, and not after, because it's easier to keep track of how much you've covered and how much is still pending, by means of the compiler being unhappy.

NOTE 2: Migrating constructors to setup methods, for instance, works roughly the same way, you just need to make sure you include \n for multi-line values.