Assuming you create a library to do some calculations, you use TDD to build it without problems, right? Now you must implement the code that actually uses this library. The client could be a Java Servlet or a CLI Program, for example.
Must this client code be built using the TDD concept? You write tests for these clients? Is TDD solely about design of the library, or do I need to worry about the client code?
I will answer your question more directly below after I give some info on TDD.
It helps to remember that TDD is actually a design process that happens to involve unit testing and following the Red-Green-Refactor cycle. It's a design process because within each Red-Green-Refactor iteration, you write the test first for code that doesn't exist. You're designing as you're going.
The first beauty of TDD is that the design of your code is guaranteed to be testable. Testable code tends to have loose coupling and high cohesion. Loose coupling and high cohesion are important because they make the code easy to change when requirements change. The second beauty of TDD is that after you're done implementing your system, you happen to have a huge regression suite to catch any bugs and changes in assumptions. Thus, TDD makes your code easy to change because of the design it creates and it makes your code safe to change because of the test harness it creates.
Now, to actually answer your question. Because TDD is a design process and not a testing process, it helps to use TDD in as much of your code as is reasonable because wherever you use it, your design will benefit from the TDD process. In fact, I prefer to start implementing features starting with the client because it helps me focus on customer scenarios first (see this link about Presenter First for more info). Typically, the way this works out if I'm implemeting something using Model-View-Controller/Model-View-Presenter/Model-View-ViewModel, I'll start using TDD with the Controller/Presenter/ViewModel, won't test the view because it will be a thin wrapper with no logic (and it's expensive to implement and maintain to verifying views with automated tests), and will move things into the model as it makes sense.
TDD (Test-driven development) is about building the entire thing. However, you can certainly limit it to just the libraries or other aspects of the application.
One of the tenets of TDD is that you write the test, then write the code to meet the test. For example, you might have a spec that says to make a method that divides two numbers. You would create an empty method with the expected parameters and write a test that passes in values and verifies the result is what is expected.
Now, initially, the tests will fail. They are supposed to. It's only when you provide the correct implementation that the tests will succeed. Once the tests are succeeding then you are essentially done; unless, of course, there are additional requirements.
Point is the tests should be driven by the requirements of the application. The code should be written in such a way that the tests pass. It's only when the tests are passing that you are done.
it depends on you client logic. if it's mostly UI thing TDD can be overkill and give you headache. but if your client has some logic that theoretically could be split to separate library - this logic can be effectively implemented with help of TDD
No, there are no musts. It's up to you to use TDD if you want and apply it whenever you wish. However, there are best practices and reasons to do things a certain way.
TDD is a way of working driven by writing tests before you implement things. Chris already gave a good explanation to this in his answer. The rationale is that by writing the tests you need to first think what you want as a result and you need to design things in a way so it can be used (tested).
I'm wondering why you wouldn't use TDD for the client code as well as you're already using it for the library? Tests are essential for good design and quality software.
Must this client code be built using the TDD concept?
Yes. All code is written this way.
You write tests for these clients?
Yes. How else would you know it works?
Is TDD solely about design of the library,
No.
or do I need to worry about the client code?
Obviously, you must use TDD for all code all the time. Otherwise, you're not really using testing to drive development. It's not TDD if the design is not driven by testing.
Why treat it differently? It's still code that you must know if its broken. And the design must be supple enough to accept changes in the future. Sounds like TDD should help.
Granted there would be some difficulties in case you're using frameworks that aren't test-friendly. But even then, there are ways to partition them into a Not-TDDed test-unfriendly layer that calls into a TDDed-presentation layer.
