Tag Info

Hot answers tagged

7

You should keep doing what you're doing. Repeating yourself is just as bad an idea in test code as in business code, and for the same reason. Your colleague has been misled by the idea that every test should be self-contained. That's quite true, but "self-contained" doesn't mean that it should contain everything it needs within its method body. It only ...


4

The point of unit testing is testing your code's functionality in isolation. To the extent that your code is simply a wrapper around an external library, it doesn't really have any functionality to unit test. It may be useful to unit test the NULL and nil values, as you suggest. However, unit testing the call to the library doesn't seem worthwhile. ...


2

Despite the other answers to this question, there is in fact a lot of behaviour in this method, and therefore a lot of things that could go wrong if we don't test them. Here are the cases I would check: When view is not empty and data is not empty, then both view and data are set in the Crashlytics object. This test is sufficient to get statement coverage. ...


2

It depends. In general, having repeating constants declared in only one place is a good thing. However, in your example, there is no point in defining a member VALID_NAME in the shown way. Assumed in the second variant a maintainer changes the text name in the first test, the second test will most probably be still valid, and vice versa. For example, lets ...


1

I would actually... not go for both, but I'll pick yours over your co-worker for your simplified example. First things first, I tend to favor inlining values instead of doing one-off assignments. This improves code readability for me as I do not have to break my train of thought into multiple assignment statements, then read the line(s) of code where they ...



Only top voted, non community-wiki answers of a minimum length are eligible