Thanks for the great work.

Isn't this just about migrating from MSTest?

Where do we want to display this? As a header on the landing page?

The first 44 examples, are about migrating from MSTest.
The last 60 examples are on rewriting FA assertions.

Yes, I thought next to documentation or examples.

I see now. So what's next? I see it's still WIP.

I have implemented failing tests for all examples, and thought about including the failure message for all examples to give proof how the rewrites improves.

are there plan for writing Analyzers for the rewrites?

@Meir017 I don't have any concrete plans.
But only because I don't have any experience in writing analyzers.

I'll keep ignoring this PR as long as it's WIP. Tell me if this is no longer the case.

I still want to add the failure messages to each example, so it's still WIP.

@SaroTasciyan, you mentioned some examples you wanted to add.

Almost all of the items in my list (NUnit) is covered. Missing ones are assertions regarding; string equivalency, DateTime and some others which might not have an equivalent in MSTest. If that's the case, I don't see the value it would add since they are already covered in the documentation.

Regarding the best practices part; It can be extended (in time) with chained assertions (And, Which), ShouldBeEquivalentTo, string equivalency / wildcard and FleuntDateTimeExtensions demonstration.

They don't need to have a MSTest equivalent, as long as there is a "wrong" and a "right" way to write it.

When you're new to FA, even after reading the documentation (for the first time), you might not be familiar with how to write idiomatic assertions.
These docs give examples, where you can search by fragments of your smelly assertion to find better alternatives.

In my opinion, they don't need to go into this part.

Converting from MSTest to Fluent Assertions.

That's why I listed them in this part (which I assume is best practices)

Rewriting assertions for clearer intentions and better failure messages.

I have finished adding the examples and failure messages I had planned.
The remaining part would be layout.
I'm not familiar with how GitHub markdown turns out as html, but when looking at the .md file, the are multiple things I'm unsatisfied with:

• The margins, that you have to scroll horizontally.
• That snippets are not top+left aligned.
• Missing whitespace conservation.
• Better syntax highlighting?
• A Table of Contents.

Layout is really not my strong side, so could use ideas/help, if this should become prettier.
@adamvoss You seem to be an expert?

@jnyrup I am really sorry I keep letting this slip through the cracks. I will try looking into this tomorrow, and if not then for sure this coming week.

I lied, I just took a quick peak now. It looks like there is an error in the HTML because I get a nesting table, but didn't take time to track it down.

Try this for inspiration (its not great but should give some ideas on things you can do):

<table>
<thead>
<tr>
    <th>
        MSTest
    </th>
    <th>
        FluentAssertions
    </th>
</tr>
<tr>
    <th>
        Failure Message
    </th>
    <th>
        Failure Message
    </th>
</tr>
</thead>
<tbody>
<tr>
<td markdown="1">
```c#
Assert.IsTrue(actual);
```
</td>
<td markdown="1">
```c#
actual.Should().BeTrue();
```
</td>
</tr><tr>
<td markdown="1">
> Assert.IsTrue failed.
</td>
<td markdown="1">
> Expected True, but found False.
</td>
</tr>
</tbody></table>

Some of the problems will need to be fixed via CSS. Regarding the page itself, if wanted to structure data into CSVs, I can help you use Liquid templates to build populate a table and avoid the sort of issue it has now with an error somewhere in the table.

TOC can be done automatically too (see the documentation page):

## Table of Contents ##
* TOC
{:toc}

Good work!

Thanks for the tips @adamvoss that helped a lot
The pages are now generated with Jekyll using Liquid templates to fetch the data from yaml files.

As there to my knowledge isn't a way to see the generated page here without pushing to master, here are two screenshots:

Wow, I ran it locally and that was a great step!

The next part is really out of my area of expertise. Does anyone reading this have design or CSS experience?

Someone who really knows this stuff could probably do some responsive design stuff that makes it flow well onto mobile too.

If it is just me trying to figure this out, my approach would probably be:

• Make the tables a fixed width (based on the current SASS variable for content width)
• Make the messages word-wrap when they would be too long for the box
• Manually add line breaks in the assertions multi-line if they would be too long on their own.

I have proposed two pull request to this which hopefully will bring it close to completion:

jnyrup#1
jnyrup#2

I have made some final suggestions at jnyrup#3. Once those changes are decided on I'd recommend squashing the history. (I don't know if you have strong opinions on squashing or if @dennisdoomen will require it, this just looks like history that is better squashed to me; don't worry about squashing my commits, I don't need attribution for them). Then I'd recommend @dennisdoomen review it for possible inclusion.

My only nit-pick would be that the horizontal scroll bar on code blocks should never appear when the windows is maximized (on a sufficiently large screen). But, since all the examples are "close enough" I am not motivated enough by the issue to recommend blocking on that issue.

@adamvoss GitHub has a squash-and-merge function, so no worries.

GitHub has a squash-and-merge function, so no worries.

It is generally not a big deal and I cannot speak for Dennis on this front, but I can give the perspective from being as a package maintainer elsewhere. While GitHub added the squash option, when contributors expect the maintainer to use it shifts the responsibility for writing a good commit message to the maintainer. Instead of everything presented as-desired so all you have to do is confirm its good and click the merge button, you have to stop and think up a good message.

There is plenty of room on GitHub for different usage patterns, so choosing not to squash is still a correct/valid decision.

I prefer properly squashed and documented commits myself. This is what I require in my professional projecs and which I practice myself. So if somebody offers me a PR with three commits, I assume this person carefully squashed his work into these three commits and will merge them as is. If the PR only includes a single commit, I'll squash-merge it.

Thanks for the clarifications both of you, it makes perfect sense.
My laziness should not shift the burden onto anyone else.

I don't have any outstanding issues left, so from my perspective it's done.

Well, then somebody should remove the WIP prefix.