Tag Info

Hot answers tagged

70

The hardest part of doing unit testing is getting the discipline to write tests first / early. Most developers are used to just diving into code. It also slows down the development process early on as you are trying to figure out how to write a test for the code. However, as you get better at testing, this speeds up. And because of the writing tests, the ...


61

In many ways I agree with your team. Most unit tests are questionable in value. Since the vast majority of tests seem to be too simple. It is much harder to write good testable code than just working code. There's a large percentage of the developer community that believes in just get it to work, versus code/design quality in itself. And an even larger ...


30

Management understands it will take longer to develop and maintain software when you don't have full access to test hardware. You need to take this into account when doing your estimates. Part of the acceptance criteria for putting your software into production should be that you have a way to maintain the software under most circumstances without stopping ...


25

Having just started trying automated tests in our team, the biggest disadvantage I've seen is that it's very difficult to apply to legacy code that wasn't designed with automated testing in mind. It would undoubtedly improve our code in the long term, but the level of refactoring needed for automated testing while retaining our sanity is a very high barrier ...


24

The main culprit is mocking/stubbing the Database or anything not simple. And there is your problem. Everyone makes good points about how to integrate unit testing into your environment. How to force people to do it enough that they see the practical value and it "sticks". But if it's super painful to do, and/or provides no benefit, it won't stick. ...


21

You pretty much nailed the most important ones. I have a few minor additions, plus the disadvantage of tests actually succeeding - when you don't really want them to (see below). Development time: With test-driven development this is already calculated in for unit tests, but you still need integration and system tests, which may need automation code as ...


17

Perhaps the most important disadvantage is ... tests are production code. Every test you write adds code to your codebase that needs to be maintained and supported. Failing to do so leads to tests you don't believe the results of, so you have no other choice. Don't get me wrong - I'm a big advocate of automated testing. But everything has a cost, and ...


17

You need to start with something small, simple to automate, and high value. Pull down some sweet, low hanging fruit, and you will be able to sell the process. Show how it saved someone a late night or a weekend call. Then you can expand out from there. To do automated testing well, you need someone who is a resource and an evangelist, and who has buy ...


16

Copy-pasted and then edited test cases are often fine. Tests should have as few external dependencies as possible, and be as straightforward as possible. Test cases tend to change with time, and previously almost identical test cases may suddenly diverge. Updating one test case without having to worry about breaking other cases is a Good Thing. Of course, ...


14

I wouldn't say these are entirely applicable disadvantages, but the few I hit most are: Time taken to set up the test in a complex enterprise application. Handling old tests that fail incorrectly, in other words, the system has evolved and now the tests are wrong. False confidence from patchy or unknown test coverage. Test coverage that is patchy can ...


13

You're trying to solve a problem that isn't yours to solve. Management needs to prioritize access to the equipment. That may mean you end up with greater access, but it may also mean you end up with less. Present the challenges you have in an objective format to your management team and ask them for guidance. Your presentation would be a lot stronger if ...


11

Follow these ground rules: 1) Testing only works if you run the tests regularly. Make tests run on every build, or before every checkin, or just every morning, it doesn't matter. You can have everyone on the team take responsible for ensuring they run tests, or if your team isn't that responsible you can automate it. But you have to have all your tests ...


10

1. Does it really work? Yes, it does - if done properly. The point is that testers needs to adjust and extend their automated scripts after engineers implement new features. 2. No one is really experienced or knows how to properly do automated testing. Get a consultant (someone who knows how it is done properly). Or, invest more time. The ...


8

Repetition is the root of all evil That is right! Repetition is the root of all evil. Probably it was Knuth saying in his book “Premature optimization is the root of all evil”, but I think it’s repetition. Whenever you look at a program or you’re writing one and you discover some kind of repetition: Remove it! Kill it immediately… whatever but get rid of ...


8

Presumably you have some sort of architecture that connects buttons and other widgets to actions -- click on save and the save function should be called, etc. Assuming you have good test coverage of the actions themselves via unit or integration tests, the goal of automated UI testing is to insure that the widgets are all making proper calls to the ...


8

It is interesting that the business is more pro-testing than developers! It sounds to me like your biggest challenge will be to overcome your developers resistance to change; they need to re-define their understanding of their jobs to include unit testing. Nothing can help you more than early unit-testing successes to help your developers overcome their ...


8

One thing that I haven't seen clearly addressed in the answers above is that unit testing is essentially a public good and a private cost. I've written a blog post about it here. What it comes down to is that while a suite of tests benefits the team or an individual developer, writing the test is a cost to the one doing it, most of the time. In short, ...


7

The opencv image processing library does it by saving the image and comparing it to a reference image - it has a bunch of c++ test functions and macros to handle approximate image matching etc.


7

Tell your manager you'd like to automate some of the tests that you're responsible for, work the extra hours and do it. Use an open source tool (there are a bazillion of them here) Then demonstrate the value of them to the team. Nothing wins arguments better than demonstrated success.


7

I'd say the main problem with them is that they can provide a false sense of security. Just because you have unit tests it doesn't mean they're actually doing anything and that includes properly testing the requirements. In addition automated tests can also include bugs themselves, so that brings the question over whether unit tests need testing themselves ...


7

They are many reasons why introducing automated testing might fail. I think that it boils down to the fact that programmers tend not to change their coding habits and are not fully capable of embracing unit testing. Many people who want to start with automated testing try to introduce them for an existing code base. They will try to write integration tests ...


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


6

One thing about automated testing is that it requires you to write code to be testable. This is not a bad thing in and of itself (in fact it's good because it discourages a lot of practices that as a rule should be avoided), but if you're trying to apply unit testing to existing code then the chances are it's not been written in a testable way. Things ...


5

It's still pretty bad to cut and paste. There are a few problems. Your tests may well be brittle, because you are vulnerable to something that requires a change in all that copy-and-pasted code. Will you have to rewrite all the tests? If you can't encapsulate the logic into helper methods outside your tests, you can't write tests of those helper methods ...


5

An important rule to test everything that is database related is to completely isolate it from the rest of your application. The ports and adapters architecture is a really good example. The database is regarded as an external plugin through an adapter to your application. The same goes with all the 3rd party subsystems. For testing how your app would ...


5

Simulate the failure / exceptional situation. Your mock objects are crash test dummies and you already know what can possibly go wrong, it shouldn't be hard to emulate it (you know because you've already prepared for it, if you don't, well, you'll soon find out ;). And... it's always amazingly fun to physically unplug your database server while your ...


5

At the end of a sprint, whatever you deliver should be of production quality, that's one of the pillars of scrum. If it's not done at the end of the sprint, it could drag on for ages as you find new stuff to add and new stuff to fix. Get it done and get it out the door. If you need a reason: because you want that feedback only customer usage can get you. ...


4

Though automation testing has many advantages, it has its own disadvantages too. Some of the disadvantages are: Proficiency is required to write the automation test scripts. Debugging the test script is major issue. If any error is present in the test script, sometimes it may lead to deadly consequences. Test maintenance is costly in case of playback ...


4

Ruby is a fine choice for a general purpose scripting language on Linux, OS X, etc. But I recently needed to write some scripts that would work on every version of Windows from 2000 through 7. VBScript didn't have the functionality I needed (talking to SOAP web services for example) and PowerShell isn't available for Windows 2000, so I looked outside the ...


4

A large part of this mass of tests is for their collection implementations. They've written generic tests that exhaustively test the collection interfaces, and this generates a suite per implementation. See, for example, classes called CollectionAddAllTester, ListIndexOfTester. This is all backed by a library called testlib, which ships as part of Guava. ...



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