Return to Answer

I think the test is reasonably well named (imho).

If you assume you write the test against a black box (meaning you don't know how the controller code is implemented) then yes you should compare all properties. Someone could have forgotten to copy a property for example. This is especially the case for later when new properties get added (as a regression test). If you find yourself writing code like that a lot then there are several ways to automate this comparison.

I prefer to use human readable strings in unit tests. Makes it easier to read. However once you start doing integrations tests like hitting a test database you want to possibly generate some more exotic strings (non latin characters) to make sure that what you put into the db is also what you get back out and not some garbled nonsense. Some databases can be nasty in that regard.

If you find yourself creating the same post over and over again then you have some options:

• If it's just inside one test fixture then create the post in the Setup routine.
• If it's across multiple test fixtures then yes extract it into a test utility class.

I think the test is reasonably well named (imho).

If you assume you write the test against a black box (meaning you don't know how the controller code is implemented) then yes you should compare all properties. Someone could have forgotten to copy a property for example. This is especially the case for later when new properties get added (as a regression test). If you find yourself writing code like that a lot then there are several ways to automate this comparison.

I prefer to use human readable strings in unit tests. Makes it easier to read. However once you start doing integrations tests like hitting a test database you want to possibly generate some more exotic strings (non latin characters) to make sure that what you put into the db is also what you get back out and not some garbled nonsense. Some databases can be nasty in that regard.

If you find yourself creating the same post over and over again then you have some options:

• If it's just inside one test fixture then create the post in the Setup routine.
• If it's across multiple test fixtures then yes extract it into a test utility class.