Hot answers tagged

100

Should savePeople() be unit tested? Yes. You aren't testing that dataStore.savePerson works, or that the db connection works, or even that the foreach works. You are testing that savePeople fulfills the promise it makes through its contract. Imagine this scenario: someone does a big refactor of the code base, and accidentally removes the forEach part of the ...


60

No, integration tests should not just duplicate the coverage of unit tests. They may duplicate some coverage, but that's not the point. The point of a unit test is to ensure that a specific small bit of functionality works exactly and completely as intended. A unit test for am_i_old_enough would test data with different ages, certainly the ones near the ...


32

Usually this kind of question comes up when people do "test-after" development. Approach this problem from the point of view of TDD, where tests come before the implementation, and ask yourself this question again as an exercise. At least in my application of TDD, which is usually outside-in, I'd not be implementing a function like savePeople after having ...


12

The primary value such a test provides is that it makes your implementation refactorable. I used to do a lot of performance optimizations in my career and often found problems with the exact pattern you demonstrated: to save N entities into the database, perform N inserts. It's usually more efficient to do a bulk insert using a single statement. On the ...


11

Should savePeople() be unit tested Yes, it should. But try to write your test conditions in a way that is independent from the implementation. For example, turning your usage example into a unit test: function testSavePeople() { myDataStore = new Store('some connection string', 'password'); myPeople = ['Joe', 'Maggie', 'John']; savePeople(...


10

The short answer is "No". The more interesting part is why/how this situation might arise. I think the confusion is arising because you're trying to adhere to strict testing practices (unit tests vs integration tests, mocking, etc.) for code which doesn't seem to adhere to strict practices. That's not to say the code is "wrong", or that particular ...


8

Another point I like to add to Killian's answer is that unit tests run very quickly, so we can have 1000s of them. An integration test typically takes longer because it is calling web services, databases, or some other external dependency, so we cannot run the same tests (1000s) for integration scenarios as they would take too much time. Also, unit tests ...


7

You can do two things: First, use parameterized tests to minimize the duplication of the test code: cases([ [0, [1, 8, 9]], [1, [0, 2, 8, 9, 10]], // more testcases here ]) .it('sample', function(n, expected) { expect(getNeighbors(n)).toEqual(expected); }); Second, partition your testcases into equivalence classes where ...


5

Should bakeCookies() be tested? Yes. How should a function like this be unit tested, assuming you think it should? It's hard for me to imagine any kind of unit test that doesn't simply mock dough, pan, and oven, and then assert that methods are called on them. Not really. Look closely at WHAT the function is supposed to do - it is supposed to set the ...


5

Look at the following diagram. It illustrates the relationship between Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD): Notice that the inner loop, TDD, is enveloped by the outer loop, ATDD. Requirements (illustrated by the Acceptance Criteria box) drive the creation of automated acceptance tests, which in turn drive the ...


3

I think you're overthinking it. Look at it from the perspective of the user of your package, upgrading. Is it safe for them to do with no code changes? Then bumping the 'z' version of x.y.z is entirely appropriate. The alternative here is to not release an updated version at all, since you can't (or shouldn't be able to) release new code that has the same ...


3

The key here is your perspective on a particular function as trivial. Most of programming is trivial: assign a value, do some math, make a decision: if this then that, continue a loop until... In isolation, all trivial. You just got through the first 5 chapters of any book teaching a programming language. The fact that writing a test is so easy should be a ...


2

Should savePeople() be unit tested, or would such tests amount to testing the built-in forEach language construct? Yes. But you could do it in a way that would just retest the construct. The thing to note here is how does this function behave when a savePerson fails half way through? How is it supposed to work? That is the sort of subtle behavior that ...


2

Change the hardcoded endpoint so it can be changed. Read the endpoint from a file containing all your settings. Its pretty easy to do, and allows for other settings to be changed according to other parameters. Possibly the easiest thing for you to do is to read the file if it is present, or default to a fixed value if not - this allows you to drop a new ...


2

Say it's broken. Say you're thinking about something else entirely and don't have a lot of patience for this bug. Which test do you wish had been written now? I test as much as I can get away with. At some point you have to stop and get paid. Keeping that in mind, it's not simply behavor. It's the boundaries. Your behavor is 'show me the neighbors'. ...


1

Should savePeople() be unit tested, or would such tests amount to testing the built-in forEach language construct? This has already been answered by @BryanOakley, but I have some extra arguments (I guess): First a unit test is for testing the fulfillment of a contract, not the implementation of an API; the test should set preconditions then call, then ...


1

You should also test bakeCookies - what would/should e..g bakeCookies(egg, pan, oven) yield? Fried egg or an exception? On their own, neither pan nor oven will care about the actual ingredients, since none of them are supposed to, but bakeCookies should usually yield cookies. More generally it can depend on how dough is obtained and whether there is any ...


1

I think your question boils down to: How do I unit test a void function without it being an integration test? If we change your cookie baking function to return cookies for example it becomes immediately obvious what the test should be. If we have to call pan.GetCookies after calling the function though we can question whether its 'really an integration ...


1

I think it's quite alright to just bump your patch version component if you want to make a new package with no changes other than additional tests. In a way you've just improved your "documentation" a bit.


1

There is the law of diminishing returns. Assuming you write tests for the riskiest code first, the value generated by further tests diminishes over time. Unit tests are code, so they will contain bugs (just like all other code). Fixing those bugs takes time. In my experience unit-tests contain far more bugs than the system they are testing, and fixing ...



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