Tag Info

Hot answers tagged

7

I'm going to have to make a couple of guesses here You mention EF so I'm guess the mocks in question are related to the datalayer? Since you are using EF, I guess your Repository presents an IQueryable and your Models construct queries within themselves? This would lead to you then having to craft you mock with data which is consistent with the various ...


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 ...


6

Dependency injection is very easy to take too far. You should use is whenever it decreases your overall effort, not because someone says it's a "good practice". That said, I don't see any fundamental difference between collections and other data used in constructors. If they are liable to change often, or are hard to mock for testing otherwise, go ahead and ...


4

This strikes me as a bit extreme, and overkill. I think it's a case of taking the common charge to never use new() in a class a bit too literally. Injection is useful for having classes consume dependencies whose implementations can change or are (or need to be) replaceable. For unit testing, it's useful to get rid of your own classes that are already under ...


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. ...


4

For unit-testing the findByBrand method, there is no real difference between passing in a Brand object or just an ID. The difference is more relevant for the code calling findByBrand. In the large majority of cases, that code should already be dealing with Brand objects, so passing that as an argument to findByBrand makes the most sense. The only reason ...


3

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. ...


3

I would test this as a black box. That means, I would only test the "interface" of a function, like I've never seen it's implementation, which I consider a subject to change. For a given example, I may check: Resulting array length ... bounds (I assume they are 0..num-1) Behavior in case of argument is zero (empty array as a result) ... is negative ... is ...


3

I would make a single unit test that provides some input and checks that the output is correct. Maybe 1-3 others for bad (negative, null, zero) input. And I would leave them all automated since this sort of this is tailor made for unit testing. I don't particularly care (in this case) that I'm retesting sin and Array.new. For one, I shouldn't know/care ...


3

This sounds to me like a break-down of communication at a couple of levels. Since you've also not stated what your position in the project is, I'll assume that you're a regular dev who's working under an architect. Breakdown of Workflow Firstly it sounds like there's not a properly defined way to handle bugs as they're entered into the tracking system. ...


2

1) It is very hard to test static void methods but they must do something so what is it they do? If they modify global state you could read that global state, but the best thing is to refactor them into a better structure. 2) Unit testing is only for public methods. Even if you test all methods you can probably not input all parameter combinations so even ...


2

Concept is good enough! Now, you must decide on what did you build - integration or acceptance tests and support/enhance them for single purpose. Here is the difference: Integration tests are used by developers to verify that application is basically working and run often from dev machine. TDD tests and bug reproduction tests goes this way. Integration ...


2

Pros and Cons As with any situation where there's a judgement call to be made, it's worth weighing up the main pros and cons. I'll summarize them as I see them, then go into some aspects a little deeper to try to show why- although there are some situational aspects- in the large majority of cases the factors pretty heavily favor a particular answer. Pros ...


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 ...


1

You say the sin function is well tested an you trust it. You're probably right that it is well tested. So sin (0) is 0, sin (90) = 1, sin (180) = 0, sin (270) = -1 and so on, right? You see, even if the function does 100% correctly what it is supposed to do, it doesn't mean it does what you think it should do. But in your unit test, do you care whether the ...


1

Ask yourself what the purpose of this function is. Write your tests based on that. That you are using a well tested library is an implementation detail. Should you decide to reduce the number of tests because that implementation detail allows you to do so, then you have to make sure that there is a test that would warn you about the implementation changing ...


1

for simple scenarios In your example of arr_of_sins, it has two dependencies: Math.sin and Array.new, however, both of these are used statically and thus to be confident in your tests you must treat it as you wrote the Math.sin and Array.new methods yourself in the class your testing. This sounds completely ridiculous, but this is the problem of static ...


1

The answer to this question "are mocks in unit tests dangerous in dynamic languages?" is "Hell yes!" The following article explains the dangers. They describe a scenario where an interfaces method name changed. For example, changing a methods name from error() to errors(). If we are mocking the error() method in our tests, they will never turn red to alert ...


1

Before I start I will add come context to question to highlight the problem. Consider: class SUT { public function tested(MyInterface $x) { $this->hidden($x->myMethod()); } protected function hidden($x) { $x->aMethodOfSomeObject() } } //Somewhere in test: $sutInstance($myInterfaceMock); Now. Your MyInterface::MyMethod returns ...


1

You don't have to test for the correct return type in a dynamically-typed language, unless the method is specifically designed to return a specific type (i.e. a Factory). Rely instead on other kinds of tests that are more meaningful from a program logic perspective. To give a simple (and admittedly contrived) example, if I expected a method to return a ...


1

Whether or not you need to use a unit testing framework is up to you. Any dependency will need to be faked so that logic can be tested in isolation. With legacy code where the dependencies are not visible a mocking or faking framework can help expose those dependencies for you and replace them so you can test that code easily without major refactoring. In ...


1

Since you always pass an empty dictionary to the constructor, in my opinions this is bit too extreme. Only advantage I can see is that when you unit test, you can pass a mock dictionary and verify add/remove methods are called. However same can be achieved by simply using count on the custom collection. So I believe this is an overkill.


1

Resolve behavior, not data (with some exceptions, eg. constants). If your business logic needs this data structure, then the business logic is responsible for initializing it, by using new or a factory. Then it can store this data structure in a cache or pass it around to other class through a method call. The container shouldn't have any responsibility in ...



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