TL;DR
Unless your Definition of Done excludes testing as one of the criteria, you must include testing in your overall estimates for the Product Backlog Item. Whether you treat testing as an implicit task or an explicit task is not prescribed by the framework.
Estimates Should Include All Aspects of the "Definition of Done"
Should the initial estimate for the development of the task INCLUDE man hours estimated to take the story to completion or should we have additional hourly estimates on the test tasks?
In Scrum, the deliverable for each Sprint is a potentially-shippable increment that achieves the Sprint Goal and meets the "Definition of Done." Your estimates for each Product Backlog Item (or user story, if you use that format) should always include everything required to meet all elements of the Definition of Done, including testing, documentation, validation, and anything else the team has agreed is required to ensure an increment is truly complete.
In general, elements of the Definition of Done are understood to be implicit aspects of each Product Backlog Item (PBI), and are simply rolled into the PBI's overall estimate rather than broken out as individual tasks for each item or user story. However, if you break out testing for each item as explicit tasks on your Sprint Backlog, then you should certainly estimate those tasks the same way as any other task.
This really amounts to an accounting issue. Ensuring that testing is accounted for in your overall estimate of the level of effort to complete a Product Backlog Item is a more agile estimation technique than the false sense of accuracy one gets from assigning exact hours to proposed testing tasks—especially since there's often a lot of ping-pong between testing and development in agile techniques like Test-Driven Development—but there's nothing wrong with estimating testing tasks explicitly as long as you are doing so consistently across all your Product Backlog Items.
The reason most shops don't do this is that if you're going to account for testing separately from development, then you should also have tasks and estimates for all the other elements of the Definition of Done as well. This generally leads to more process overhead, a false sense of precision, and is rarely more accurate than the aggregated estimate for a Product Backlog Item that implicitly incorporates the full Definition of Done.