The application I'm referring to is an enterprise application with web  interface. In general in all aspects of this enterprise application, testing some parts are automated and some are based on unit test  but one challenge is, to cover all possible scenarios running additional functionality, integration and regression tests will help us to capture any other faults and that would be based on written test cases. these are all prior to handing over to Test team and that applies to all parts of the enterprise application. after that Test team have their own methods and again that includes automated test specially for P& C + functional test.

for majority of automated tests we do not use a special tool (publicly known) other than some scripts that we write but it might get tricky specially when testing remote connections and for some i.e. memory management, purify could be a good choice.

I'm not sure how much it would be advantageous for web  applications, and as far as I know it only works under Windows platform, but in a 4-tier total solution project in 2003 I'd setup Rational Robot for our test  team and made them work with it; They still use it, and I guess they live with it happily ever after ;)
I don't believe it will be a time consuming to see its benefits, I guess you can get the trial version:
http://www.ibm.com/software/awdtools/tester/robot/

I remember twice in two Enterprise web  base projects , by the
beginning of the project, we decided to develop the systems in Test
Driven development  way.

Test Driven Development(TTD):
• Think about what you want to do.
• Think about how to test  it.
• Write a small test. Think about the desired API.
• Write just enough code to fail the test.
• Run and watch the test fail. (The test-runner, if you're using
something like JUnit, shows the "Red Bar"). Now you know that your
test is going to be executed.
• Write just enough code to pass the test (and pass all your previous
tests).
• Run and watch all of the tests pass. (The test-runner, if you're
using JUnit, etc., shows the "Green Bar"). If it doesn't pass, you did
something wrong, fix it now since it's got to be something you just wrote.
• If you have any duplicate logic, or inexpressive code, refactor to
remove duplication and increase expressiveness -- this includes
reducing coupling and increasing cohesion.
• Run the tests again, you should still have the Green Bar. If you get
the Red Bar, then you made a mistake in your refactoring. Fix it now
and re-run.
• Repeat the steps above until you can't find any more tests that
drive writing new code.

We provide an infrastructure for developers to made it easy unit
testing and set some policy for this purpose. The idea of Testing
First, Refactoring and Continuous Integration was working well but
after some weeks, by the lack of time and reaching deadline/ delivery
time, bad coaching and so on, developers got lazy to write unit
testing and finally completely forgot this development process.

Test Driven Development provides a means of ensuring that the code
developed as a team will work as expected, and minimizes the time
spent consolidating and testing the application (Functional testing,
load testing, Code Analysis, Unit testing, profiling and UAT testing).

When I first started employing automated testing methods in my daily
practices, at first it seemed very hard. I had to create mock objects
for every dao and feed that mock to the webpage or action I used.
Normally the page would have some jsps so I needed to bring up a
servlet runner to run that jsp, also asserting results from the html
pages needed parsing which was another problem. And as my business
logic was scattered everywhere from DAO's to actions and jsps, testing
the simplest scenarios would involve tackling all these problems.
Eventually I learned that if writing tests are hard, this means
there's some flaw in my design. It has been said that "Design for
testing", which means design to test  easier. So I started looking for
smells in my design and improving testing, and things have changed
since then for me. Here are a few tips I can share with you :

- First of all, testing web  & persistence layer is hard enough, So
remove as much business logic as you can from these two and put them
in simple POJOs which dont depend on any other layers. These objects
can be tested using simple unit tests,with no need for mocks, special
contexts, environments etc. I know you already know all this, but its
too important to be left out.

- Embedding UI logic or java code in pages is considered evil, and has
many drawbacks. One is reducing the testability of the logic, because
both creating and asserting results get harder. So if you're using web
frameworks who use these kind  of template engines, try to leave as
little as possible to the pages to render.

- Depending on the framework you use, normally they provide tools to
be able to test your actions/pages/objects... . Those tools will help
alot so use them as much as you can.

- Using Spring to inject your dependencies can help when you need
services in your actions/pages. At test time you replace the services
with simple mocks and get on with the real tests. As a rule of thumb,
any object that looks up its dependency itself will be harder to test.

- A practice I normally use is I divide my UI logic in two parts, one
manages the behavioral aspects of the components I use, and is a
simple POJO independent of the web environment  which can be tested
easily, and another part wires the components together(This part is
dependent on the framework) This way I can write simple unit tests for
the behavior of my components easily. I guess this method can only be
used in component-based web frameworks.

- To test the html output of the pages, Selenium is the ultimate tool.
Its very easy to use and has a great effect on the whole process. But
its drawbacks compared to java based tools like httpunit is httpunit
test can be used in load testing your application, but with selenium I
dont know any good method.

- The tools I use are Selenium,TestNG, along with Springs testing
facilities and my own web frameworks tools. I dont know any other tool
in javaland thats good for testing. Normally I believe testing should
be easy enough not to need tools.

These were my few tips on the subject, maybe you can clarify a bit so
we could zoom on a specific part and discuss that.

These days I lean more toward functional testing than unit testing, for UI development. Thankfully, app servers have become snappier so it's easier and more fun to record UI tests using something like Selenium, or write UI functional test  code using its supported scripting system. I've even contributed code to some of the mocking frameworks previously, but nowadays I tend to keep them to minimum and use them only when absolutely necessary. Mocks are rather artificial and ugly. If you want to maintain the testing code, and hence do TDD as the project grows, then don't overuse mock objects.

In the company that I'm working in, TestNg is being used, and we can't commit anything unless there is a test  case for that one, and before deploying all the test cases are ran, so they're sure that nothing's broken, and also we use Emma to get the rest coverage report.
and I have found it really useful to write test cases and i believe that's why their applications are really working!!
but we have just one difficulty with test data, we are not sure how to generate the data, right now I'm using Xstream to generate some xml files based on entities and some parsers to read the data from these xml files and persist them to data base, but this is a really controversial issue here and we're still discussing it more than two months, I was wondering if you have any idea about how to generate the data?

I want to ask from the guys who have experience test  Driven Development in Enterprise web  based application ,

we always have some problem with this method because it's really time consuming especially if you want write test for DAO's

in many cases the time you should spend is not convenient , For instance if you finish a usecase in 5 days how much do you think we should add to its time when we develop it with employing TDD ? if you think it shouldn't extend the time it's really surprising!

I agree with the tips that Mr Iman suggested although I still have some problems with it's time ,and i want to know more about your experience especially in term of time.

TDD has a bit of learning curve IMHO.

But once you get familiar with your test  frameworks you will get a lot faster.

Think about it as an upfront investment… you will have less bugs (much less support and maintenance) and you won’t introduce the same bug in future releases.

Making changes to one part of the application will not break other parts of the application…

let me correct this a bit: ...it _was_ really time consuming especially if
you want write test  for DAOs.

Have a look at this and enjoy life: http://www.unitils.org/

there are some cons and pros for test  driven developement:
cons:

1 - taks twice time to write the code for a module before giving it to customer
2 - most of the changes in iran refrers to UI.how do you want to test UI automaticaly?

pros:

1- your support time would cut to one third or less.no hidden side effects when you change some part of the code.
2- time estimation for final product, would be much acceptable at the end ,and it is very important for managers.

when a time it estimated for a usecase it should contain the dev test  effort as well. if 5 days is not enough, then the view on that UC must have been very optimistic or a step has been missed. but test should be considered in uc estimate effort.

DAOs are part of a uc or couple of UCs, the test that you write depeneds on the uc, no one here can tell you how much time you need to add to the estimate effort to include testing, that really depends on the uc but definitely will increase the dev time. usually (considering one process) there is at least unit test & functionality test involved in each single uc, but again that is case by case basis

estimating time on a uc, depeneds on the vision on the particular project, experience on similar projects and also the parameters of the type of process involved in development

Writing tests takes time, now. It also takes time to keep tests up to date and passing. It is code which must be maintained. So it's a tax you pay now and forever.

But, they can win you back time, later, when you debug to fix a problem, refactor with less fear that you might break something, deploy with more confidence and so on.... It can be a well paid tax, if you do it with discipline and focus! It doesn't work when the poor developer does it with blindness and resistance! He feels like the government (project manager) is robbing him with some stupid tax

To sum up a bit on unit vs functional read this :
http://beust.com/weblog/archives/000444.html
and on amount of tests, this :
http://beust.com/weblog/archives/000463.html

Also, I greatly believe most of the toughness in writing tests for
developers(ones that I see) is due to their bad design, as I said
"Design for Testing"(see http://ootips.org/design-for-testing.html).
Unit testing makes classes and modules interdependent and that helps
you write functional tests easier. But however, you can get away with
not writing unit tests, but practically should never leave out
functional tests.

It's the repetition of the test  that wins you time later. If the code is not going to change, you'd better hand-test it and then leave it when you're sure it's all good. But even in a small software, everything is changing every day, and there's a huge dependency graph that makes it impossible to track changes. So, instead of testing everything all the time (at least on each release), you make some robots to test everything for you. Of course this is more expensive than hand-testing a few times, but later it pays off. Especially in large scale systems that the time for test would increase exponentially over time.



A VERY important point is that you should maintain tests the same way that you should maintain the software. So, "designing" tests to be maintainable is very important, as you would design your software to be maintainable.



Anyway, I'm not a big fan of TDD for the whole project. And I'm not very happy with the Unit Testing either. The last time I used TDD was for the development  of a core class library for a project which is the architectural glue. I wrote unit tests instead of defining the interface, and asked a team mate to develop the library in a way that all the tests are passed. That was rather a definition than a test, but it had the benefits of TDD too.



Otherwise, I use functional tests. A large software cannot work without a test team. Spending time to write automated test scripts is a good investment, because you need a test team in a way or the other. Why not ask them to write repeatable tests? So, I'm not using TDD, rather "Test Driven Maintenance". When a change occurs, the functional tests can tell you what went wrong, or which test should be changed. (But I have big troubles for windows apps on this!)



Unit testing every aspect of every component is very expensive, and I think it is suitable for rare cases, like when you need an extremely high quality software (like for airport control towers), or you plan for a big number of re-uses (like product line architectures). Otherwise, if a fault in a specific component does not affect the working of the whole application, then it's not a bug.

As i explained before we always have to write test  cases and the time we spend to write a test case is usually more than the time you spend on the main class, because you have to consider different results and cases that might be reached in the class, and the most important part is the Assertions, we have to spend as much as time is needed to complete the case, it really worth it.

Thanks for your advices although I have already known about the benefits of writing Test and
I definitely know that DAOs are Part of a UC and you should consider it's time But I wanted only some estimation
As you mentioned you can not estimate my case ,let's talk know about your Case and your experience how you think it changed your time
and how you think it can save your time in the future.

I know that is really hard to compare them in a term of Time but I only want some estimations .

There are no rules for estimating time it takes to write tests for a use case. But it improves as you progress. Some code may be hard to test. That's a sign that the code is not modular enough. If you refactor the code to fix its coupling problems then the next similar code will take much less to test. Needless to say you can write reusable test  base classes which you can derive from in many cases. So over time it takes less and less if you refactor mercilessly your code and tests.

And I haven't seen any reliable case studies showing how much you save time later on.