I generally agree with 2-8, and 10. I think points 2 and 10 are pretty
subjective and must be applied very pragmatically.
--
View this message in context:
http://wikimedia.7.x6.nabble.com/Architecture-Guidelines-Writing-Testable-Code-tp5006129p5006712.html
Sent from the Wikipedia Developers
Hey,
Because of this, I can be fairly confident in recommending thata my
team avoids the use of TDD.
Clearly you are not a fan of TDD. Which is entirely fine. If you adopt this
practice or not is a personal choice, and not one that should be forced
upon anyone. Like with all practices,
As the dumb ass trying to merge a lot of the code last year at
Wikidata I would say stop bitching about whether to make tests or not.
Any tests are better than no tests, without tests merging code is pure
gambling. Yes you can create a small piece of code and be fairly sure
that your own code
On 06/04/2013 11:37 AM, John Erling Blad wrote:
It is like writing a
document with no spell checker vs using a spell checker.
Which would be the right moment to remind you of the Cupertino effect
that illustrates so well how the combination of automation and trust in
that automation is known to
Hey,
My own experience is that test coverage is a poor evaluation metric
for anything but test coverage; it doesn't produce better code, and
tends to produce code that is considerably harder to understand
conceptually because it has been over-factorized into simple bits that
hide the actual
On Tue, Jun 4, 2013 at 12:36 PM, Jeroen De Dauw jeroended...@gmail.comwrote:
Hey,
My own experience is that test coverage is a poor evaluation metric
for anything but test coverage; it doesn't produce better code, and
tends to produce code that is considerably harder to understand
Test coverage is not a quality metric, it is a quantity metric. That
is it says something about the amount of tests. The coverage can say
something about the overall code given that the code under test infact
reflect the remaining code. As the code under test usually are better
than the remaining
On 06/04/2013 12:57 PM, Nikolas Everett wrote:
The thing is quite a few of us have seen cases where people bend over
backwards for test coverage, sacrificing code quality and writing tests
that don't provide any real value.
Probably better expressed than I did.
My point is: clearly test
Can you give any examples of real code that become less clear after it
was rewritten for testability, and explain why it is worse after the
rewrite?
On Tue, Jun 4, 2013 at 7:20 PM, Marc A. Pelletier m...@uberbox.org wrote:
On 06/04/2013 12:57 PM, Nikolas Everett wrote:
The thing is quite a few
On 04/06/13 22:29, Jeroen De Dauw wrote:
Hey,
Because of this, I can be fairly confident in recommending thata my
team avoids the use of TDD.
Clearly you are not a fan of TDD. Which is entirely fine. If you adopt this
practice or not is a personal choice, and not one that should be
Thanks for your thoughtful reply, Tim!
Am 03.06.2013 07:35, schrieb Tim Starling:
On 31/05/13 20:15, Daniel Kinzler wrote:
Writing Testable Code by Miško Hevery
http://googletesting.blogspot.de/2008/08/by-miko-hevery-so-you-decided-to.html.
It's just 10 short and easy points, not some
I have no qualms with any of the guidelines. They are good guidelines but
like all guidelines they are made to be bent when appropriate so long as
you leave a good explanatory comment. My main concern is that the article
is about test how to write more unit testable code which is something I
Hey,
He claims that just because you have guard rails you shouldn't stop paying
attention and expect them to save you.
Being someone who practices TDD, I fully agree with that. It is not because
you wrote tests first and got a 100% coverage that you proved your code to
be correct and bug free.
Le 2013-06-03 16:20, Jeroen De Dauw a écrit :
Absolutist statements are typically wrong.
Please, don't miss an oportunity to provide people with the joy of
reading paradoxes : Absolutist statements are *always* wrong.
There, fixed that for you. ;)
(sorry, I couldn't resist…)
On Mon, Jun 3, 2013 at 10:20 AM, Jeroen De Dauw jeroended...@gmail.comwrote:
4. Don't write automated tests at all and do lots of code reviews and
manual testing. Sometimes this is really the most sensible thing. I'll
leave it to you to figure out when that is though.
Absolutist
On Mon, Jun 3, 2013 at 7:20 AM, Jeroen De Dauw jeroended...@gmail.com wrote:
So my question is not how do we write code that is maximally
testable, it is: does convenient testing provide sufficient benefits
to outweigh the detrimental effect of making everything else inconvenient?
This
On 06/03/2013 10:20:26 AM, Jeroen De Dauw - jeroended...@gmail.com wrote:
snip
* Regression detection
* Replaces manual testing with automated testing, saves lots of time, esp
in projects with multiple devs. Manual testing tends to be incomplete and
skipped as well, so the number of bugs caught
Am 03.06.2013 18:48, schrieb Chris Steipp:
On Mon, Jun 3, 2013 at 6:04 AM, Nikolas Everett never...@wikimedia.org
wrote:
2. Build smaller components sensibly and carefully. The goal is to be
able to hold all of the component in your head at once and for the
component to present such a
On 04/06/13 00:20, Jeroen De Dauw wrote:
Hey,
He claims that just because you have guard rails you shouldn't stop paying
attention and expect them to save you.
Being someone who practices TDD, I fully agree with that. It is not because
you wrote tests first and got a 100% coverage that
On 31/05/13 20:15, Daniel Kinzler wrote:
When looking for resources to answer Tim's question at
https://www.mediawiki.org/wiki/Architecture_guidelines#Clear_separation_of_concerns,
I found a very nice and concise overview of principles to follow for writing
testable (and extendable, and
When looking for resources to answer Tim's question at
https://www.mediawiki.org/wiki/Architecture_guidelines#Clear_separation_of_concerns,
I found a very nice and concise overview of principles to follow for writing
testable (and extendable, and maintainable) code:
Writing Testable Code by Miško
21 matches
Mail list logo
