I was assigned a task I think doesn't make sense. Should I approach my boss about it?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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!

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.