What method of development You think is right?

The algorithms that I know tend to write in large chunks, and then a couple of runs rule all. Usually it's just typos. But with the libraries that we work with for the first time, or algorithms that I write rarely, usually debug in parts. It's easier, because at the stage of getting used constantly but somewhere sfeylyat.

I can't help feeling accustomed to the right (according to TDD) work: first write tests, then code such that the tests did not work, and only then run to work.
\r
Of two:
— lazy to write tests for trivial code (that is, there is no code "on paper", but "in the head" he is already)
— lazy to write the tests, providing for everything, for example, that methods of access to the database will return any kind of nonsense, and not either correct data or an error. Or, say, the design return new SomeClass() returns not an instance of SomeClass.
\r
I'm probably writing tests is still misunderstood, especially with regard to the testing of related objects (e.g. combination of controller, model, repository)

Martin Fowler endorses the second approach.

Depends on the circumstances — there are modules that will not testisi from addiction there and so on. In this case, I bring the work up to any logical unit on which to conduct a logical test. Sometimes get quite large blocks.
\r
In General, the approach is to split functionality into several logical "chunks" — say no more than 1-2 days work ideally — and, accordingly, wrote-attester-forgotten.
\r
In General — try to find a middle ground when a piece of code is still a single, whole, performing a single functionality, but on the other hand, it is amenable to testing, in contrast to the suspended spherical functions in a vacuum
\r
PS: write the application, so a minor breakdown does not work — in the same MVC controller often simply suspended in the air without a model and view correctly will not olesterol...

Use both. The choice depends on the complexity of the code. But more "in the back" — Write a lot of code, then testing it all at once, because the "debug log" has not been canceled.

Depends on how you write these "lot of code". Nothing prevents you from committing every change to the code or add features, and tests to write a separate commit after adding a fairly large amount of code. But every commit is to check the code for passing the existing tests. I like this approach quite satisfied.

Some mix: I try to every night all gathered and worked without obvious errors, but spend a thorough testing before release, i.e. once a month or even more.