Is it bad practice to compare string representation on an object instead of its properties during unit tests?

It's perfectly ok.

When you compare string representations you are testing:

• toString(),
• everything toString() uses to create the string representation, and
• not necessarily any properties at all

The way unit tests work (the good ones anyway) they don't force you to use a particular implementation. So a 'string representation' test is blissfully unaware of whether properties exist at all. toString() might use them. Might use something else. All we learn from the test is if whatever it uses works.

So it's perfectly ok. So long as you don't care whether properties exist.

Is it bad practice to compare string representation on an object instead of its properties during unit tests?

It's perfectly ok.

When you compare string representations you are testing:

• toString(),
• everything toString() uses to create the string representation, and
• not necessarily any properties at all

toString() might use properties. Might use something else. All we learn from the test is if whatever it uses works.

The way unit tests work (the good ones anyway) they don't force you to use a particular implementation. So a 'string representation' test is blissfully unaware of whether properties exist at all.

So it's perfectly ok. So long as you don't care whether properties exist.

Is it bad practice to compare string representation on an object instead of its properties during unit tests?

It's perfectly ok.

When you compare string representations you are testing:

• toString(),
• everything toString() uses to create the string representation, and
• not necessarily any properties at all

The way unit tests work (the good ones anyway) they don't force you to use a particular implementation. So a 'string representation' test is blissfully unaware of whether properties exist at all.

So it's perfectly ok. So long as you don't care whether properties exist.

Is it bad practice to compare string representation on an object instead of its properties during unit tests?

It's perfectly ok.

When you compare string representations you are testing:

• toString(),
• everything toString() uses to create the string representation, and
• not necessarily any properties at all

The way unit tests work (the good ones anyway) they don't force you to use a particular implementation. So a 'string representation' test is blissfully unaware of whether properties exist at all. toString() might use them. Might use something else. All we learn from the test is if whatever it uses works.

So it's perfectly ok. So long as you don't care whether properties exist.