What method of development You think is right?


Warning: count(): Parameter must be an array or an object that implements Countable in /home/styllloz/public_html/qa-theme/donut-theme/qa-donut-layer.php on line 274
0 like 0 dislike
10 views
1) Write a lot of code, then testing it all at once
2) Write small pieces, which are immediately checked

In my opinion, both approaches have both advantages and disadvantages:
Approach No. 1:
+Don't spend too much time on the test is correctly written sites, Works and all. What didn't work — fixed
-It's easy to forget what I was thinking at the time of writing, or another area. Especially if the pieces are very large

Approach No. 2, respectively, exactly the opposite:
+Just wrote — if some error is detected, it is not difficult to calculate
-Spent a lot of time checking well-written plots

What do you think about this?
by | 10 views

7 Answers

0 like 0 dislike
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.
by
0 like 0 dislike
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)
by
0 like 0 dislike
Martin Fowler endorses the second approach.
by
0 like 0 dislike
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...
by
0 like 0 dislike
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.
by
0 like 0 dislike
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.
by
0 like 0 dislike
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.
by

Related questions

0 like 0 dislike
4 answers
0 like 0 dislike
3 answers
0 like 0 dislike
5 answers
0 like 0 dislike
1 answer
0 like 0 dislike
1 answer
110,608 questions
257,186 answers
0 comments
28,057 users