I think they aren't.

Unit tests help me to think about what I want exactly from a method (for example). But there are times when I know what method should return me, but very aproximately. For example, there are several acceptable results, but I just do not know what is the best in my case. Unit test will not solve this problem. Even more, if I choose one way from start and create unit test, I may miss a better way, so unit test may suppress my creativity.

This may sounds strange, but think a bit about this. A possible solution in this case is prototyping. Try several approaches without unit tests and the choose the most appropriate. Any other ideas?

UPDATED Jan 28:

I really do write tests first, but sometimes I wonder if this is always good for system architecture. Well, in most cases it is. The basic flow is like that: 1. write a code (for example, controller). And just realize that existing API is insufficient. 2. think a bit about possible extension and make a decision 3. write a test for this new desired method. 4. write a code for this test. 5. review the code and refactor on a "lower level" (rename, extract method, ...) 6. after awhile, review API and refactor on a higher level (new interfaces, classes) I don't think that this process really suppresses my creativity. Refactoring is a key. Discussion about this topic at Artima

As you maybe know, TargetProcess built with NEO framework. During last several months I had a good chance to dig into NEO. NEO is good indeed, but it has some weak areas. See details below.

Strength:

1. Allows to test without database (mock objects are already there, so it is very easy and cool). Initially I wrote tests with database, but then try to use in-memory data. It worked great and tests results were the same. So NEO really resolve UnitTests-Database problem.
2. Provides code-generation for SQL and Entity classes. In fact, I need more flexibility and going to modify code-generation templates and main xml dtd (which is the source for code-generation). But modifications seems to be easy.
3. Works very stable. I did not found any bug yet.
4. It really speeds-up development. I can't say exactly, but I feel that my performance increased by at least 20-30%.

Weakness:

1. There is no entity inheritance in NEO. In my case additonal effort was required to workaround this issue and still that workaround was not very good.
2. A little of documentation, so learning curve is pretty high (however, tutorial is on the way, so the situation will change in the near future).
3. Query mechanism is poor. No joins, no group by, no sum. I appreciate domain model, but in some cases SQL provides much more power and I want to have such an option at least.
4. Queries like TitleList matchingTitles = factory.Find("PublicationDate < {0}", new DateTime(2003, 1, 1)); have hardcoded field - PublicationDate. If I change the name of the field, this will not throw an exception. So I should replace them by hand (well, IDEs do have good find tools). But, anyway, this should be resolved during compile-time. NEO has templates for entities, but templates are slightly cumbersome and I don't like them as well. Maybe there is not good solution for this problem.

I manage performance improvements project. The main goal is to achieve good performance for large data (up to 1,000,000 records in a single table). I hope some tips will help you to improve database response time. UNION ALL instead OR You can use UNION ALL instead OR in queries. UNION does not perform the SELECT DISTINCT function, which saves a lot of server resources from being using. Moreover, some DB servers could optimize such queries (or even execute them in parallel). However, query become more complex. For example SELECT name FROM users WHERE level > 0 or is_admin = 1 May be rewritten as SELECT name FROM users WHERE level > 0 UNION ALL SELECT name FROM users WHERE is_admin = 1 The second query works much more faster on large tables. This is true for SQL Server and Oracle as well. Denormalized tables (or views) Denormalized table or view combines data from different tables into a single. As a result, no JOINs required in queries and this improves performance. This tip helpful for various lists. Tables splitting Sometimes one large table could be splitted on several smaller tables. This method may work pretty well with UNION ALL. Sure, queries become more complex and there will be several places to store almost the same data, however performance will be increased. If you don't know other ways - try this. Hints and indexes Hints are great, especially for Oracle. It is not recommended in general to use hints for SQL Server, since it may even slower query execution time. Hint tells DB server what index should be used for particular query. Oracle hint example: SELECT /*+ INDEX (users USERS_H_R) */ name FROM users These techniques are unusual. But if you stuck, try them.

We changed host provider and the site was not available during last four days. Maybe there will be minor troubles during next few days. Sorry for any inconvenience.