Tag Info

New answers tagged

0

It's more than just whether you can mock a Brand object or not. First, I'll assume your Product is really a Data Access Object, and not a simple Java Bean/DTO/POJO. The real question to ask is, how long will this assertion hold? Assume 234 is the brand id of the brand in database. Will simple int values become long in the future, necessitating all ...


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


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


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


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


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


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


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


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


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


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


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


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


0

If you work with a stream to import (as suggested by Killian) then you can test each of the functions to get individual values by mocking that stream. Mocking the stream means that you setup the next few bytes before calling the to be tested function and let the test fail when it requests more than the needed number of bytes. After the function all those ...


0

The purpose of your implementation is to get comething decoded. It's not to move data from disk to memory, that is just an incidental auxiliary function. Therefore, your code should be decoupled so that the importer works with a stream, and in practice it should be coupled to a standard file-reading implementation (preferably from the standard library). ...


-3

I am very familiar with this problem! Also, controversially, I believe it is caused by AGILE DEVELOPMENT! Think about it. Agile tries to drive devs faster by getting them to concentrate on completing what is asked for and move on to the next task. This is great, but it puts a huge pressure on the person writing the spec. If they miss something out it wont ...


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


0

is there any way to mitigate the risk of incorrect mocks and implementations? In python-mock, you can specify a mock spec. A spec constraints what methods and attributes are available in the mocked object, thus you'll get an error if the system under test (SUT) try to call or access something unexpected. My concern is what happens if we accidentally ...


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


0

I'd say that mocks are dangerous in every language. Let's say that I call: priceCalculator.calculate( qty, item, isPlusCustomer, isSenior); What if: isPlusCustomer and isSenior are supposed to be in the other order? qty was supposed be a weight, not a qty. you needed to initialize the priceCalculator first before using it? There are ...


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


0

The Red-Green part of the cycle tests the test. If you have a hunch that a particular edge case needs to be considered, or just to show that it's been accounted for, I'd argue it's legitimate to artificially force a failure to prove that a test locks the implementation into a correct behavior. In the example case, it's probably unnecessary. But, if you ever ...


0

Mocks are acceptable in this case, but you don't need it. Instead of unit testing method(), instead unit test just the portion that handles the response. Extract a function that takes ResponseData (of whatever kind is appropriate) and then performs the action. Instead of mocking, now you just construct a ResponseData object and pass it in. You can leave ...


0

What I've done, and it works: Have all code call webservices through proxy. The proxy calls a class that statically knows if we are using proxy or not and redirects accordingly. Mocks are just HashMaps that for each request returns a given reply. Run the tests several times in this order: 3.1 First all webservices are tested. From each machine, even ...


0

Yes you should always test the system with all real-world architecture if you can, some problem may be only occurred in real system/data tests (out of memory/locked connection/environment stableness). If the business logic and data communication is proven to be working great, the next thing you should focus on will be stress test for the service: Regards to ...


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

Without gettting into an argument over what a 'unit' test is: Yes you should test your sql/sprocs. especially if you (foolishly) put business logic in them. you can use database snapshots to set up dbs https://msdn.microsoft.com/en-us/library/jj851212%28v=vs.103%29.aspx 'Test all your methods' is a good rule because it allows no room for ...


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


-1

I think you should try Morelia: https://morelia.readthedocs.org/en/latest/ It passes your 4-point requirements list: It's BDD tool built on Python's unittests module Executed tests are textual description. If you can automatically run traditional Unit Tests then Morelia can be run same way. I think the most common CI for github is Travis-CI which can run ...


0

What I have done in the past is use Acceptance Test Driven Development. ETL code is often distributed across different stages/languages and technologies AND tightly coupled. Most ETL process are dependent on the sequence of transformations in the pipeline. The risk in using unit test only in ETL is that it won't cover the integrations. The sequencing of ...


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


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


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


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



Top 50 recent answers are included