Tag Info

Hot answers tagged

25

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


24

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


18

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


17

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


16

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


15

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


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


13

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


13

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


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.


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


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

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


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

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


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

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


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


6

Making Software: What Really Works, and Why We Believe It has a chapter on TDD (now TDD is not what you were asking for, but this is the only credible book I know of to mention unit-testing in any shape or form).


6

Look into using Hypersonic, or another in-memory DB for unit testing. Not only will the tests execute faster, but side-effects aren't relevant. (Rolling back the transactions after each test also makes it possible to run many tests on the same instance) This will also force you to create data mockups, which is a good thing IMO, as it means something that ...


6

Evolving the Team's Culture This might be the most difficult part of implementing testing processes in your organization. Every team reacts to change differently. Some people embrace the opportunity to try something new, and some are perfectly happy in their ways and see no reason to change. I can tell you this: nobody likes a fascist. Forcing people to ...


6

For the duration of the development, have both. Keep the old tests as assurance that you haven't broken anything, write new tests (from scratch) to help you design the classes as they should be. At the end, run through and remove anything that's defunct in the old tests. Be careful in this analysis; don't remove something because you think it should be ...



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