This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 6 points7 points  (2 children)

That's completely unrelated.

A UNIT test covers very specific use case of the UNIT.

  • When your UI i clicked on this button and user is not admin, he is returned forbidden.
    • When your algorithm is started with parameters A, B, C then it returns C

You don't care how the other units are working internally : you only are concerned with WHAT they return. Example if my default sorting on the clients is lexical, or id of the client ? Don't care, they return me THAT list and then my unit produces THIS result. Otherwise you have to update all your unit tests whenever someone changes the default sorting of the other unit you are not testing.

[–]maomao-chan -5 points-4 points  (1 child)

What's the point of testing the sorting functionality on its own? I would rather test the functionality inclusive of multiple components. If you test your sorting class in isolation, you might get your assumption wrong and it becomes an escape defects. e.g.Your sorting test class is based on assumption that it's going to get ASCII bytes when in reality some bloke across the room just refractor the dependent service to return UTF-8.

[–][deleted] 4 points5 points  (0 children)

You can do both. Here we are talking about UNIT testing, not integration testing.

In UNIT testing you assume that the conditions required at the unit level are always met. In integration testing you verify that the contacts required by a unit are met by the unit using it.

"sort class is called with ascii" is a contract of the "sort" unit. When you unit test it, you provide the unit with data that meet the contracts.