Tag Info

Hot answers tagged

27

It's comparing oranges and apples. Integration tests, acceptance tests, unit tests, behaviour tests - they are all tests and they will all help you improve your code but they are also quite different. I'm going to go over each of the different tests in my opinion and hopefully explain why you need a blend of all of them: Integration tests: Simply, test ...


25

The Rspec Book, among other BDD resources, suggests a cycle like this: In essence, the process is: While behaviour required Write an integration test for a specific behaviour While integration test failing Write a unit test to fulfil partial behavior While unit test failing Write code to make unit test pass ...


21

TL;DR: As long as it meets your needs, yes. I've been doing Acceptance Test Driven Development (ATDD) development for many years now. It can be very successful. There are a few things to be aware of. Unit tests really do help enforce IOC. Without unit tests the onus is on the developers to make sure they meet the requirements of well written code (in so ...


21

You're going to find yourself writing a lot more tests, of much more complicated, interesting, and useful behavior, if you can do so simply. So the option that involves var input = new Parser().ParseStatement("x = 2 + 3 * a"); is quite valid. It does depend on another component. But everything depends on dozens of other components. If you mock something ...


20

In my opinion you should mock the webservice calls if this is a unit test, as opposed to an integration test. Your unit test should not test whether the external webservice is working, or whether your integration with it is correct. Without getting too dogmatic about TDD, note that a side effect of turning your unit test into an integration test is that ...


19

My first recommendation would be to not mock types you don't own. You mentioned HTable being a real pain to mock - maybe you should wrap it instead in an Adapter that exposes the 20% of HTable's features you need, and mock the wrapper where needed. That being said, let's assume we're talking about types you all own. If your mock-based tests are focused on ...


19

When your dev team and your QA team don't not talk to each other, there is a certain risk that some tests are unnecessarily done twice, and some others are forgotten. One worst case scenario is when your dev team has implemented some nice automatic integration tests, which run in a few minutes or hours, and your QA people tests the same things manually, ...


17

What's the decisive advantage of unit testing vs integration testing? That's a false dichotomy. Unit testing and integration testing serve two similar, but different purposes. The purpose of unit testing is to make sure your code does what it is supposed. In practical terms, the unit tests make sure that the code fulfills the contract outlined by ...


16

Testing team (the so called QA team in some organization) insists that the dev team should share their (Dev team's) test cases with them. Sure, QA should have a general understanding of what is covered by unit/integration tests, and what is not. Their arguments are Dev test cases are the starting point for the QA testing. ...even if their ...


15

For me unit tests should not deal with the database, integration tests deal with the database. Integration tests that deal with the database should in practice have a empty database with a tear up and tear down approach, using a transaction based approach is quite a good way to go (i.e. create a transaction on setup and rollback on tear down). What your ...


15

The easiest metric is to ask, "when was the last time this integration test legitimately failed?" If it has been a long time (there have been a lot of changes) since the integration test failed, then the unit tests are probably doing a good enough job. If the integration test has failed recently, then there was a defect that was not caught by the unit tests. ...


15

First, lets talk about what your goals are: you obviously don't want to test "file formats" - you want to to test your different FileReader implementations you want to find as many different types of errors as possible by automatic tests To reach that goal in full, IMHO you have to combine different strategies: first, real unit testing: your ...


14

There's an awesome book that covers what you're doing in great depth. Working Effectively with Legacy Code describes a number of techniques for doing just what you're doing. The table of contents is available here. It had been recommended to me for years, and I only recently picked it up. Basically, yes you're correct. Test for the functionality that the ...


12

You may transfer existing (already processed files in previous runs) output files into the output folder just to simulate the work of the third party API in the unit test code. This will suffice if you are unit testing your own functionality and not the third party functionality.


12

Well, I have used the TDD like approach to let the tests / requirements evolve the design of the program. The problem was that over one half of the development time as for writing / refactor tests Unit tests work best when the public interface of the components they are used for does not change too often. This means, when the components already are ...


11

You will not be able to fix all the tests together. I think you should focus on the word improvement versus overhaul. Neither management not developers will agree on an overhaul but if you show that there is a way to improve things without affecting the project negatively, they will be more likely to listen. First, you cannot 'fix' or refactor existing code ...


11

Integration vs. unit tests You should keep your unit tests and your integration tests completely separated. Your unit tests should test one thing and one thing only and in complete isolation of the rest of your system. A unit is loosely defined but it usually boils down to a method or a function. It makes sense to have tests for each unit so you know ...


11

When doing unit tests the "proper" way, i.e. stubbing every public call and return preset values or mocks, I feel like I'm not actually testing anything. I'm literally looking at my code and creating examples based on the flow of logic through my public methods. This sounds like the method you are testing needs several other class instances (which ...


10

While unit testing you are not expected to test with a database, or at least, not with a database you haven't prepared for unit testing. Testing with a database, and as such, testing different layers of your application at the same time is generally seen as integration tests. With unit tests you are supposed to test only what your method does, what it ...


10

Unit tests are just one level of the hierarchy of automated tests. Unit tests exist to verify that the code you (the developer) have actually written behaves the way you thought it should when you wrote it. There are two caveats inherent in unit testing. First, coverage is not exercise. You may execute every line of code in your codebase via one or more ...


10

philosophically, tests that use mocks should take priority over tests that use a live endpoint I think at the very least, that's a point of current ongoing controversy amongst TDD proponents. My personal view goes beyond that to say that a mock-based test is mostly a way of representing a form of interface contract; ideally it breaks (i.e fails) if ...


9

I must admit I would take it as a rare gift to arrive at a project where they already have a significant number of unit/integration tests - I have never had that luck in my life so far. Even if not all of them are working as they should, there is already a great deal of effort put into it, and even if the team and management don't always follow best ...


9

Instead of just saying "Because it's a unit test", lets talk about why we might want to have a test that doesn't depend on a database. Isolated Failures We want a failing unit test to quickly identify where an issue is. The narrowest unit test failure already has two possible sources, both the unit under test and the test itself. Every dependency is ...


9

You've laid out good arguments for and against unit testing. So you have to ask yourself, "Do I see value in the positive arguments that outweigh the costs in the negative ones?" I certainly do: Small-and-fast is a nice aspect of unit testing, although by no means the most important. Locating-bug[s]-easier is extremely valuable. Many studies of ...


9

I'm not familar with those services but CI in general is good for It gets rid of the "Builds on my machine" excuse for comitting bad work. If it doesn't work in CI it doesn't work. You can then take the known working code from there and use it for things like Continuous deployment. Some provide a history so you can tag Version 1.0, 1.1 etc so its ...


8

Short answer: you need a test suite for a third-party vendor API - so you will have to develop one. Don't expect anyone else to do it for you, and don't expect a "magic bullet" for generating automatically the right tests. Some things you could try additionally: ask the vendor if they provide a list of "breaking changes" for each new release ask them ...


8

Yes, of course it is. Consider this: a unit test is a small, targeted piece of testing that exercises a small piece of code. You write lots of them to achieve a decent code coverage, so that all (or the majority of the awkward bits) are tested. an integration test is a large, broad piece of testing that exercises a large surface of your code. You write ...


7

However, it implies that large parts of the applications code are not covered by tests. Why? Because if you have units (and you need a lot of units to get your Unit Tests right) you need code that wires the units together. This code, IMHO, will get complicated enough that it deserves to be tested on a more granular level that integration tests while it ...


7

An important rule when doing repeatable tests (automated or not) is to make sure that the test data is always in the same state before the tests start. This should be ideally assured for every single test of your test suite, so you can interchange the order of any tests at any time. How you achieve this is up to you. For your scenario, it may make sense to ...


7

Are you sure everyone will run the tests? E.g. those commits when you're late for the plane - and that change is tiny and really-really can't break anything. Are you sure you want to run the whole testsuite on your system before every push? Some testsuites run for hours (UI automation) or execute slow tools like valgrind. Are you sure you will run the ...



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