The test code should receive just as much love as your production code. For readability, maybe even more. If anyone else than you(including you two weeks after leaving the code) is supposed to understand what is going on, then you should make your code nice an crisp.

This means:

• Extract building of test data into builder classes.
• Extract multible assertions into separate assertion methods.
• Be very precise in your naming. Assert.That(x4, Is.EqualTo(y16*2*3.1415), ASS_ERR_TXT_56) makes very little sence to most readers.

Taken to the extreme, tests can be written so they are almost as easy to read AND understand as prose. The extreme tester would probably say that a unit test more than 10 lines long is a bad one.

The test code should receive just as much love as your production code. For readability, maybe even more. If anyone else than you(including you two weeks after leaving the code) is supposed to understand what is going on, then you should make your code nice an crisp.

This means:

• Extract building of test data into builder classes.
• Extract multible assertions into separate assertion methods.
• Be very precise in your naming. Assert.That(x4, Is.EqualTo(y16*2*SOME_VALUE), ASS_ERR_TXT_56) makes very little sence to most readers.

Taken to the extreme, tests can be written so they are almost as easy to read AND understand as prose. The extreme tester would probably say that a unit test more than 10 lines long is a bad one.