It very much depends on your commercial model and what your client wants (so ask them). A few things to think about:
What will help your client make a decision?
The client is making a decision - whether to proceed with the project or not and which options to choose. The information you provide should help them with this and be at an appropriate level to do so.
So what will help them prioritise, what will help them select which functionality doesn't provide value for money?
This is a sales document
What will help you make the sale? How can you make things look most appealing, make things look good value for money? Ideally the things you're listing look should be grouped such that they have clear business benefits and sell themselves.
As part of this think about hiding contention - I've lost count of the number of times I've argued about testing ("your developers shouldn't make mistakes and I certainly shouldn't be paying to have them found") so think twice about task breakdowns like that and steer clear of things they might pick on
Note: I know testing is important and I'm sure you do. You need to gauge whether that's a useful message for your customer though - some are great about it, insist on it and want to see it, others don't get it. You need to work out whether educating them is in your interest or whether you're best off just hiding it. Remember, you're in business, not education.
What are you willing to report back?
If you provide a massively detailed estimate, you're likely to be asked to report back progress and final costs at that level. If you're OK with that then fine but there's an overhead that comes with it (time recording at that level) and it can encourage micromanagement and haggling. Personally I'd keep things relatively high level.
Think about your commercial model
There are two basic models:
a) Time and materials projects
With this you're charging for your time on a strict hourly rate and what you're providing are estimates - that is your educated guess for how long each thing will take. If things over run the client will pay more (you should notify them as soon as you know it's going to go over - never incur an overrun before you've informed them), if something takes less time than you estimated it's cheaper.
Because of the nature of the model you can be as open as you like with them and if you wish can break it down into as much detail as you want - after all this isn't something to haggle over, it's an estimate, your best guess.
That said most clients don't want to see a list of 100 tasks. Broadly speaking for a smaller project (100 man days total or less) I'd list nothing smaller than a couple of days, nothing larger than 15 days, typically no more than 10 line items) . For larger projects these might increase but if you're getting lists of 30 or 40 items you're probably at too low a level plus providing this level of detail positively encourages micromanagement from the client.
b) Fixed price projects
In this model you're charging a set amount for the development of a piece of functionality. If you estimate it's going to take you 100 days and you're done in 10, the price doesn't change and you're laughing. Similarly if it takes you 1000 days, you're screwed and you don't get to increase the price.
In this situation your estimates are none of the client's business - they're buying something akin to a product, a set of functionality for a set amount of money.
What you're providing is basically a price list for them - a list of things you're going to do with a price against each one. The level of detail is largely driven by the client but ideally it will be at the level where they're likely to pick and choose different functions to implement based on the prices you provide.
Personally similar to T&M projects I'd be looking at no more than 10 line items for a project of up to 100 man days and even beyond that you want to keep the total down because aside from anything else the time taken to estimate every little permutation is considerable.