I am building the frontend for our latest application, along with 2 other developers. With the application approaching 99% completion and ready to be shipped, I was asked to write unit tests.

I am a new programmer with 1 year of experience, so when I looked up unit testing online I found that unit tests should be written before or in parallel with whatever it is that is being developed, and not afterwards.

I feel like the task assigned to me is wrong, however I am not sure if I should approach my boss about it. I've tried talking to my teammates about this, but they don't seem to understand me.

Should I approach my boss about a task assigned to me which I do not think makes sense? And if so, how?

  • 8
    I can't imagine the expectations of your unit tests are very high. They're ready to ship and gave the task to someone with no experience or knowledge. Exactly how critical can this be? Just make sure your tests don't break the build.
    – user8365
    Commented Feb 26, 2014 at 14:39
  • 2
    Hi @hermann, I've made an edit to your question which I think brings it on-topic with the site's scope, while still getting you the answer you seem to be seeking. If I've missed anything you think is important with my edit, please feel free to edit it further, or roll back the changes. Thanks!
    – Rachel
    Commented Feb 27, 2014 at 16:33
  • 3
    Also my short answer to your question is you should approach your boss about it. Explain your concerns, and if he/she wants you to do the unit testing anyways, you should do it. Sometimes tasks which don't make sense to you are done for other reasons, such as gaining experience or to comply with internal audits. At the very least, you'll be able to add "Unit Testing" to your list of skills on your resume, and have gained experience for next time you're asked to write unit tests :)
    – Rachel
    Commented Feb 27, 2014 at 16:35
  • 6
    Yeah, unit tests should have been written at the time, but late is better than never. He's likely to explain this to you and send you back. (It's also a good way for you to learn the codebase without making more dangerous changes, so may be being performed strictly as a teaching tool.)
    – mxyzplk
    Commented Mar 5, 2014 at 15:03
  • 4
    General life tip: if you have to google the thing you've been asked to do and other people on the team have a bunch of experience doing the thing you've been asked to do, then you're probably not likely to be correctly second guessing your manager. Commented Oct 2, 2017 at 0:34

8 Answers 8


In general it is better if unit tests are written before or with the code under development. But that doesn't mean unit tests written afterwards are useless - and they are certainly better than no unit tests at all.

Unit testing written after the code can accomplish two things:

  1. You might find circumstances you weren't aware of before where the code fails. This is useful to know, and means you can fix it before the code ships.
  2. Good unit tests can be executed repeatedly after every change to the code, to check that the changes haven't broken anything. This is called 'regression testing'.

While your boss might (might!) have made a less than ideal decision earlier, he is now making the right decision.

So go ahead and write the unit tests you have been assigned. When you start the next project, suggest to your boss that you start by writing the tests. And read up on "Test Driven Development", which is what that becomes when you do it properly.

  • 3
    There is a third thing that might be relevant: If the product scope changed, and now an official validation is needed (for example, to get an FDA approval), unit tests could become a must. I had such a situation once, where the original software was designed for lab research only, but when they wanted to use the software in the production line of medical devices, the stakes were much higher suddenly.
    – Thern
    Commented Oct 2, 2017 at 8:50
  • +1 for @Nebr comment, but +1 for Michael's answer, too. Your answer explains why testing after the fact is as pointless as the OP thought, but the meat of the question is should I talk with Mgr about a task I don't see the value of, to which the answer is yes.
    – rath
    Commented Oct 2, 2017 at 9:31
  • 1
    @rath I think you missed a 'not' out of your comment. Commented Oct 2, 2017 at 12:50

I think the real question here is in the last line:

Should I approach my boss about a task assigned to me which I do not think makes sense? And if so, how?

The answer is a resounding YES, you should approach your boss. One of several things could be going on:

  • You have mis-understood the boss entirely and think she wants you to do something other than what she actually wants. If you don't ask, you'll waste a bunch of time doing the wrong thing.
  • You don't know the reasons for the request. In the real world we sometimes do stupid stuff to fulfill a requirement that makes no real sense. This comes up frequently when dealing with certifications - it may be that you know some step is useless, but you can't change the process right now for various reasons.
  • You perhaps don't have enough experience to understand why this should be done at this point. The boss can explain it and you'll learn something.
  • You've actually found a problem with what the boss wants. The boss now has a chance to change direction before wasting a bunch of your man-hours on useless work.

No matter which one it is, talking to the boss will get you the information you need to proceed.

I'd go with something like

Umm, Boss, this doesn't seem to make any sense to me. It looks like this work is useless or even counterproductive, so I think I've misunderstood something.

That puts you in the position of asking for help, not telling your boss she's wrong. It starts a conversation, not an argument, and gets you the information you need.

  • 9
    I would seriously not recommend telling the boss "it looks like this work is useless". I think you're wrong when you say that it isn't "not telling your boss she's wrong"; I'm fairly certain if one of my team members came up to me and told me "I think the work you gave me to do is useless", I'd be rather offended.
    – Adam V
    Commented Feb 28, 2014 at 14:46
  • 1
    @AdamV: It may be a cultural difference, but now you make it sound like you would be offended if a team member indicates he might have misunderstood a piece of work. Commented Feb 28, 2014 at 15:12
  • 6
    @BartvanIngenSchenau - I'd be offended if he approached his misunderstanding by using the word "useless" or "counterproductive". If you come to me and say "I'm not sure I understand why we did things in this order", I'd be able to answer that without taking offense. After I give my answer, I'd be more willing to accept criticism like "shouldn't we have done this sooner?", but when you immediately jump to "useless" before understanding the reasons, then I feel you're putting your boss / team lead on the defensive, and they won't respond as well.
    – Adam V
    Commented Feb 28, 2014 at 16:47
  • I agree with most of the answer, I think the actual approach to your boss could be better though. Something like "Could I get some guidance about exactly what my role in unit testing is?"
    – kleineg
    Commented Apr 11, 2014 at 17:42
  • There's a range in "I don't understand why we did this" that ranges from "Explain O Enlightened One" to "I might be missing something, but I don't think so" and then all the way over to "I understand you can't pour piss out of your boots with the instructions printed on the heel, what I don't understand is how even you can believe anyone thinks you know what you are talking about". Describing it as useless is a bit past "I might be wrong", particularly when, as in this case, he should be a lot closer to asking for elightment not criticizing.
    – jmoreno
    Commented Oct 2, 2017 at 23:56

One key point here that I think it’s worth addressing is this:

I feel like the task assigned to me is wrong.

In my opinion, it’s worth taking some time and adjust your perspective on the work before doing the actual work.

So, if I got it right, you find writing unit tests after the code is wrong because “the book” says that they should be written first. As in any other set-in-stone rule, it’s good to understand what stands behind it. In this case, one of the benefits of having tests written first is that it guides you to build your module/class/function in a way that is easy and intuitive to use for its client code: code that will use it. In fact tests are your code’s first client.

What I’m getting at is that even if the code was not written test-first, it will still benefit you to write tests: if it’ll happen that the code is hard to test or awkward to use, you’ll never need another theoretical by-the-book explanation of why it’s good to have tests written first.

I mean writing tests now, will give you the opportunity to evaluate your code and find ways to improve it. And even if you won’t be able to jump in and immediately improve it this time, you will next time: because you already know why.

So, what I would do is this: I’d just give it a try. Just as an experiment, just as a fun code-kata-like exercise. Be prepared to ask for a little help if it’s hard to start. But you can be sure that this will help you understand your code in new ways, and I bet that writing tests—no matter before or after— will turn out to be a trick that you’ll want to keep close to you.

Good luck!

  • 2
    Unit tests are also an excellent safeguard against regressions, if them failing breaks the build - the developer trying to 'optimize' the function will instantly know that their code is wrong.
    – Riking
    Commented Feb 28, 2014 at 6:51

It is true that unit testing up front has many advantages. However, the realities of software development will often include things that are less than ideal.

First, you are working with people and people make mistakes. Sometimes less than ideal decisions are made, and sometimes tests are forgotten.

Second, there are competing priorities for any project. Time available to build the product: quality of the product (and therefore testing of the product), resources available to build the product, and features required for the product. The code you're supposed to test could have been written when there was insufficient time to get in all the features perfectly, so they were done with lower quality.

Third, that may simply not be the process at your company. Your company's version of the software development lifecycle may specifically put all testing at the end of the project.

Most importantly, you have only been at your job for 1 year. You need to work with your mentor, team lead, and supervisor to learn how things are done there. If you come up with questions like, 'why wasn't this done during development?' then you should ask someone at your company to help you better understand the development process. We, on the internet, cannot tell you why a decision was made at your company.

  • The OP didn't say he was doing TDD. Commented Feb 28, 2014 at 2:27
  • @DJClayworth Actually, he did say that he looked up TDD and that's where he learned that you should build your tests during development. Then he edited his question, and Workplace does not announce when a question you've answered has been edited, as your answer may no longer be accurate to the question, and I didn't come back to read what I didn't see any updates for ;-). I'll try to remember to update my answer based on the edited question.
    – atk
    Commented Feb 28, 2014 at 2:34
  • Sorry, didn't look at past versions. Commented Feb 28, 2014 at 3:41
  • consider editing your answer to account for changes made in the question. The way it is written now looks confusing for readers
    – gnat
    Commented Feb 28, 2014 at 7:08
  • @DJClayworth, nor would I have expected you to ;)
    – atk
    Commented Feb 28, 2014 at 12:54

The simple answer is that although it is very late in the process to be thinking about tests, you should do them if you have the time, as they are a benefit to your development.

As regards bugs, you should also be creating/adding tests as part of the process. This also ensures that later work doesn't regress the fixes.


Anytime you are unclear about a task or why it needs to be done, then you need to discuss with your boss. However, what you don't want to do is ask undiplomatically. So don't say why I am I asked to write these useless tests. Say that you are not clear on the assignment by all means. Saying the assignment appears ridiculous to you never is. One of the critical skills to learn is how to ask leading questions to get a boss to understand that you have concerns about an issue without coming out and saying you think the boss is stupid.

Ask what exactly he wants from these tests at this point in development. Ask what he wants you to do if some of the tests fail. Ask which kinds of failures would cause the product to need to be delayed and which would need to be documented as bugs that needs fixing later. Ask if this is something you should be doing going forward as part of all development. Ask if there are sample tests from some other project. Ask what areas you should prioritize if you can't cover the whole codebase in the allotted time. Better to have 5 good tests that cover the most critical part and complex part of the application than 100 tests covering the noncritical but easy to understand things.

After writing the tests, you can suggest that doing test driven development might have been a better idea especially if you find significant problems with the code at this point in time.

Now I can think of several reasons for doing this at this point. Perhaps someone was supposed to write the tests and didn't and they need them for legal reasons. Perhaps there wasn't time to write the test earlier, but the boss wants you to get more familiar with the code, so he asked you to do this as a training exercise. Perhaps he doesn't have a critical dev task for you to do and writing tests is a way of getting productive work from you.

  • First paragraph is the only workplace related answer here at all, and exactly right. The rest belongs to software development.
    – gnasher729
    Commented Oct 3, 2017 at 19:59

In theory, writing test cases in parallel to development allows you to write better code. But in many cases, this might not work out (mostly due to time bandwidth).

So, first things first, writing unit test cases (even if it is after development), is not a useless activity. Please don't communicate the same to your manager and develop a wrong impression of yourself on him/her. Understand that unit test cases are helpful not just for you but for others who might work on the same module in future. Following are the reasons to write a test case:

  • Well written test cases act as guardians of code. i.e, assume you have a specific if-else clause written to handle a corner scenario. Tomorrow if someone new comes in and decides that this if-else clause is useless and needs to be done away with (maybe he doesn't know the corner scenario). How do you protect that code? Write a test case to capture the scenario. That way, when he runs the test case, it'll fail and give an indication towards the reason for the code.
  • Test cases allow you to monitor different scenarios which might not be caught during manual testing. Test cases allow a huge bandwidth in terms of the data that you can pass and the output you can expect. That way, you as a developer can capture wide variety of scenarios which will give you more confidence on your code.
  • Running test cases after each and every change of code allows for regression bugs to be caught (Many a times, your own fix would cause your own code to break!).

All said and done, it depends on how religiously the developers follow test case runs and how efficiently is the test case written. But please don't undermine the task of test case writing.


On new projects, is common for more tests to be written later than in parallel with development, for a variety of reasons:

1)If its a large product, you generally want to make progress on the hard architecture pieces early. Lets say it take 1 month to write module A, 1 to write module B, and 2 weeks for each module to write tests. Then you tie it all together. If you wait to do the tests first, you can't find those problems until 3 months in. If you do fewer tests in parallel and front load the development, you can find the design problems (which cost the most to fix) a month earlier.

2)Business realities rarely allow you to actually write all the tests you eventually need in parallel.

3)If the project is non-trivial, you probably don't know exactly how you'll do everything. Pieces will be written, then reworked or even replaced. (I'm on a 9 month new project now, we've already replaced the db. I just rewrote the image cache completely because the way the networking library handled threading caused too many passes to the UI thread causing perf issues. All tests on both of those would have needed to be rewritten from scratch). Spending a lot of tie test writing will require you to spend a lot of time test rewriting and test fixing. It makes no sense to write tests until things are at least semi-stable.

4)Even if you do write things in parallel, you'll miss things. Unit tests are never finished, they evolve with your app. You add more as you find corner cases you missed (which is also why unit tests don't prove your code is right- they can at most prove they aren't wrong in a way you've thought to test). You always add more tests after development as you find these.

5)Unit tests are useful over the life of the project. Even if it would have been better to have them earlier- it will still help moving forward. Writing them now is better than nothing.

  • This seems to answer the question's specifics more than the actual question (which is about whether to tell the boss, not about whether the asker is correct in their assessment)
    – Erik
    Commented Oct 2, 2017 at 8:15
  • Of the two, that's the now interesting. The actual question was something a 2 year old should have known the answer to. Commented Oct 2, 2017 at 12:36
  • Please be nice to those asking questions. Just because you feel people should know, doesn't mean they do, and we're here because we want to help them with answers.
    – Erik
    Commented Oct 2, 2017 at 12:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .