Given they've just been given the story during planning (regardless of it being a new story or not having estimated it earlier) you have a few choices.
First, you can ask the product owner if the story can be left on the backlog so that it can be properly checked and estimated during this sprint, and take it next sprint.
If that's not possible, another option is to do it in a spike - a time-boxed story to investigate something or to try something out - and then you'll have a head start for doing it next sprint.
Finally, if you really must start on it this sprint, then try and find out as much as you can during planning, and take the story but make it clear of the risk that it may not be completed this sprint. If it doesn't get completed, so be it, you've done some of it and now know a lot more about it for the next sprint.
Remember, estimates are just the best estimates with the information you have at the time, and can be revised later when you have more info.
Also remember you should be spending about 5%-10% of the sprint in refining the backlog. Doing this really helps keep the planning meetings shorter, more focused and more productive.
First, congratulations on your contract! Ok, enough celebrating, let's get down to business. ;) I've been a consultant for over 15 years -- here's my advice.
In project management, what you are talking about it "contingency" planning -- and you absolutely should do it, else you are likely to disappoint your client (and make yourself unhappy throughout the project). However, you should NOT specifically put it into the plan as it's own line item -- as then when you need it (and you most likely will), it only makes you look like a bad planner, and by definition you will be behind schedule.
There is a motto you live by: "Under-promise and Over-Deliver". Set expectations (in this case delivery time) low, but not so low that the client would be put off, and then beat the timeline (and demonstrate that you are ahead of schedule).
Instead, of one contingency block at the end of the project, you should distribute contingency planning throughout the project. Assuming you haven't already committed to delivering in your estimated 4 weeks, suggest and plan for 6, with your planned 4 weeks of effort spread out evenly over all 6 weeks. This will make you, and your client much happier, as you should generally be slightly "ahead of schedule" throughout. :)
Important: You should plan progress updates / partial demos on a frequency that:
1) mitigates the risk of building what they asked for but not what they want
2) builds customer confidence while not being overly burdensome on you. Be SURE to plan for this time working with the customer, giving demos, tweaking things, etc.
In a project of that length, that is most likely every three days or so.
Finally, when you are planning the work, front-load the most "risky" or "unknown" items first and plan the most contingency for them. Risk takes many forms -- and it's most often not the technical stuff. Generally, the biggest risk is that the customer doesn't TRULY know exactly what they want. You want to get stuff in front of them early and often to ensure you are in alignment. This means prototypes, mockups and such. If there is misalignment or misunderstanding, you want to find it as early as possible! Generally, if you find this out very early (before significant work has been done), you can renegotiate the contract to work for both parties. The biggest mistake freelancers make is delivering what the customer asked for, but not what they want. You need to understand that you are responsible for ensuring that both parties are the same page.
On riskier technical items, do enough of a proof-of-concept early so that you know you won't crash into a roadblock late in the game. Fight the tendency most people have to focus on the stuff they already know to "build momentum".
Have fun with it and I hope this helps. If you would, let us know how it went after you complete the project. Good luck!
Best Answer
My recommendation: You either include testing time in the ticket, or add a ticket to represent the testing task itself. Any other approach causes you to underestimate the real work needed.
While developer time is often a bottleneck, in my experience, there are many teams constrained on test. Assuming the limiting resource is one or the other without evidence, can bite you.
As your colleague, I haven't seen a successful organization that doesn't take testing time into account.
Addendum per your clarification: Even if devs write automated tests, particularly unit tests (integration tests do better), they are insufficient to properly test.
If there is QA people involved, their time need to be estimated, one way or another. Only if you are deciding to remove QA people from payroll, then their work time has effectively vanished and you can remove it from the estimation. But this would have side-effects that are easy to ignore. And you may still be missing performance, stress, security and acceptance testing.