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.