I'm developing a program using a library made by another programmer (he works in the same company). Recently I discovered a leak in the library, which happens under certain network conditions after a few hours of running. I filed a bug with description of conditions to make this leak happen. That developer answered that "this is not enough", "it's not his responsibility to reproduce bugs" and I have to create unit test to reproduce this bug, otherwise he doesn't do anything.

  1. Is he right?
  2. What I can do in this situation? Creating unit test is impossible, because it depends on some random network timings.

8 Answers 8


Is he right is probably a question that can't really be answered without knowing your company. However, he certainly isn't being very helpful.

I would raise the bug with him (which you've done), if it is causing an issue with your project then I would raise it as a blocker with your project manager and make it very clear that you've raised the bug with appropriate person but it's going to impact your project if it isn't fixed promptly.

I would also go over and talk to the developer and explain why it's infeasible to create unit tests but you'd be happy to show him it on your machine (assuming that's feasible?).


He is 100% right that you must provide enough information to make the bug reproducible - otherwise there is no chance to find out if any fix he provides will really work.

But - he is IMHO 100% wrong that this must be in form of a unit test. If you can describe a test scenario in a way so he can reproduce the failure (at least with a high probability in a reasonable amount of time, or by manual testing), you have a proof that the problem exists - which should set your colleague in the responsibility to fix it. Of course, if you are able to create a scenario which reproduces the bug quicker, that would be helpful for him. Ideally, one would make an automated test out of that, and it depends on your organization who has the responsibility for this.

  • 12
    So if an app crashes "every now and then", without dicernible pattern for the user, then the developer does not have to fix it because the user cannot reproduce it on command? I strongly disagree here...
    – Heinzi
    Jun 10, 2013 at 15:15
  • 22
    @Heinzi: if I get a bug report "app crashes every now and then", I would give that issue a very low priority to work on, too. The minimum thing I expect the user is to write down how often is "now and then", what he was doing exactly what with the application at the time the app crashed the last time, and the exact error message.
    – Doc Brown
    Jun 10, 2013 at 15:23
  • 3
    @user626528: IMHO the library owner is ought to try to go through the steps you tell him to reproduce the bug - he is not ought to try 500 slightly different scenarios when your description does not show up any bug.
    – Doc Brown
    Jun 10, 2013 at 15:27
  • 6
    The reporter shouldn't have to provide reproduction steps; quite often we simply attach a dump from the crashed process, especially if it occurs during an automated run. It is the assignee's responsibility to find reproduction steps so that the fix can be verified.
    – avakar
    Jun 10, 2013 at 15:49
  • 2
    (That doesn't mean the reporter shouldn't try to be helpful and provide the steps if they know them. For sporadic crashes, however, the reporter has no obligation to burn time on researching something the component owner will probably figure out faster.)
    – avakar
    Jun 10, 2013 at 15:52

Both sides should put some effort.

Library developer should put some additional effort even without unit-tests, because some issues cannot be reproduced with unit tests. Sometimes it's hardware, sometimes it's some specific sequence of correct actions from the rest of program which makes the library producing bad results.

You should put some additional effort, because after all this my not be a bug in the library, but result of incorrect actions from the rest of program (e.g. corrupted heap may make any library behaving weirdly). So it makes sense to reduce as much as possible non-library code involved into bug reproducing. And you will likely do this faster and cleaner than a person unfamiliar with code of your application.


If the author of the library is unable to reproduce the bug based upon your report, then it is unreasonable to expect him to spend a lot of time on it, let alone fix it.

But you also have a limited amount of time spend working on a product that is peripheral to your interest. Unfortunately, this may mean that the bug continues to exist, and no work is done on resolving it.

Fortunately this is not necessarily a disaster -- while in an ideal world, all software would be bug free, that isn't the case, and so we have to prioritize based upon the problems it causes US.

This means that it is indeed your responsibility to develop a reproducible test case IF YOU WANT IT FIXED. You may not care whether it gets fixed, and in that case, you have done everything that can and should be expected of you. You may want it fixed, but not enough to devote time to make it reproducible at this time. That is perfectly acceptable.

Reporting a bug to the best of your ability in the time you have to deal with it is simply good citizenship, you don't need to go beyond that unless it is necessary for your program. And you may not want to do so even then, there may be another library that you could use, or it may be possible to roll your own in a reasonable period of time. Basically it's up to you to decide what and what kind of effort it is worth to you.

  • 1
    You answer looks very strange for me. I'm fixing my bugs on my own, and don't wait for someone to do dirty work instead of me. I'd say it's primary responsibility of code author to do his best to fix his code.
    – user626528
    Jun 11, 2013 at 2:45
  • 1
    Since YOU are the one that wants it fixed now, it's your responsibility to convince him that it is worth HIS time fixing it now, instead of in 10 or 12 years when he doesn't have anything else more important to fix. theregister.co.uk/2013/01/21/kde_bug_quashed. Given an unreproducible bug, of significance X, and a reproducible bug of the same significance, I will work on the reproducible bug every time.
    – jmoreno
    Jun 11, 2013 at 19:10
  • too much ego. He is paid to work on that freaking library.
    – user626528
    Jun 12, 2013 at 2:37
  • 1
    @user626528: It's not about ego, it's about priorities -- inability to reproduce a bug lower's it's priority. Given two EOI (Execute Operator Immediately) bugs, one reproducible and one not, I would work on the one that can be reproduced first, and I would tell any other developer to do the same. And if the library isn't used that much, I might work on another project entirely -- even if the bugs in it are not as significant. If he is /solely/ being paid to work on this library AND there are no outstanding feature request or bugs other than this one, then yeah he should just do it.
    – jmoreno
    Jun 12, 2013 at 6:06

I'd be inclined to let sleeping dogs lie for now - you've raised the issue and it is assigned to him. Presumably there are processes in place to track outstanding bugs and chase these up?

If you wish to actively progress this further, I'd suggest talking to your manager to see if there are any test tools available that can reliably reproduce the issue.

From the developer's side - it would be seriously inert of them to do nothing given that you've provided the required information. It may be possible however that they have a massive workload so can't devote the time required to track the issue through.


You found a bug, you reported it and he's being a jerk about it.

Had the two of you been close friends he would have done something to help, but he'd rather just push the issue back.

You can do more, by reporting more details and trying to support your claims that it's leaking memory. Still, you have your own responsibilities and need to finish your own work.

Log as much information into the bug tracker as you can, and move on.

If you see this person again in the future. Be friendly, try to talk about common interests and understand that good relationships are far more effect way of getting things fixed, then any amount of facts you can provide to support a claim.

  • I have some sympathy with the library developer. Perhaps their viewpoint is that the application developer is trying to use the library and have caused it to crash with their code. It isn't being reported in the wild or by any other developer so to them it is a relatively low priority (or spurious) bug.
    – Robbie Dee
    Jun 11, 2013 at 13:34
  • @RobbieDee yes true, this wasn't one of my best answers. I just thought it was strange that the two couldn't work together considering they work for the same company. I mean, if the owner of the business heard an employee had to come here to get support. I wonder what he would think of that. It's not how I'd want thing to run in my place.
    – Reactgular
    Jun 11, 2013 at 14:04

Often, what I've come across in similar situations is an assumption that all bugs should be fixed and while it's admirable, it's definitely a great goal to have (lets face it we never set out to write bugs!) it is ultimately unrealistic in any project of a decent size to fix a bug just because it is a bug (if you can find it!) That's why we have project management and coding methodologies, patterns & practices etc.

So, one thing I'd say in the library owner's defence (and has been the case when I've worked on some big projects) is that dev time costs money and is a finite resource so the decision as to how a report is handled, who investigates, what tests are produced/needed and ultimately if (and if so, when) a fix is put in place is based purely on business impact. What is the impact of restarting your long running process once in a while if it fails and can you easily automate that instead (and perhaps shouldn't you be already as a defensive programming measure?) is it just time or is there more to it?

Also look at it from their point of view, a bug report from one user of an unpredictable problem in a bit of code that happens very rarely, only in conjunction with their code, possibly only on one machine and only under a set of unusual timing conditions just won't have a strong justification for a large chunk of dev time to find and fix - if it's even possible. But if it's a strong enough business case for that user to want/need to take the time to investigate more thoroughly and provide a reliable test case / application or a radically more detailed problem description than their initial one then it could be a whole other ballgame.

This is perhaps an issue of communication that the library owner has not considered putting it that way and if you've got a strong business case (such as your code is costly for the business, has a legal compliance requirement, security hole or has some other major knock-on effect) then it's time to kick it up to management and let them fight it out.

  • 1
    I have my sympathy that somebody is considering your answer (which is practical possibility) bad and down voting it. Same has happened to my answer.
    – isntn
    Jun 11, 2013 at 8:25

You have mentioned that ' I filed a bug with description of conditions to make this leak happen.'

If you are sure that description is really enough to reproduce bug then you already know exact conditions. Now, if you cannot write unit test after knowing conditions, then that clearly means that you cannot mock some of the components involved or some parts of code are too tightly coupled to allow to create practical unit test.

You should ask library owner to refactor code to allow you to create unit test. You will have to explain clearly what is in library that is stopping you to create unit test. He will have to refactor code otherwise concede that unit test is not possible with current code. Both ways, you win.

If this does not work, following are options you have:

  • You can reproduce bug with more evidences.
  • Try involving higher authority and ask him/her to evaluate your evidences.
  • Try using library in prototype application with mock environment to be coded only to reproduce bug. That way, you will be able to prove at least that bug exists.
  • 3
    It's not the OPs responsibility to create the unit test for the library maintainer.
    – Andy
    Jun 10, 2013 at 17:13
  • 6
    If the other developer is ignoring bug reports from someone there's virtually zero chance of him responding favorably to a request for a major refactoring. Also, not all types of problem are readily reproducible via unit testing: programmers.stackexchange.com/questions/196105/… Jun 10, 2013 at 17:15
  • 1
    @DanNeely: He is not ignoring, he is claiming that reporter has to do something more - which is not possible to do for reporter. And reporter has to communicate back! I have also suggested to involve authority, as this may get down to that.
    – isntn
    Jun 10, 2013 at 17:31
  • 1
    @Andy In some positions it is corporate policy that bugs are not accepted without an automated test. Jun 10, 2013 at 19:03
  • 5
    You appear confused about the proper use of voting, and whiing about it is unlikely to help your case. Downvotes are the accepted way to say "I think this is a bad answer". Offensive language should be dealt with not (solely) via down voting, but by either editing it out or flagging depending on if the rest of the answer is useful. An out of context an answer could be handled either way depending on how egregious it is. Jun 10, 2013 at 19:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.