Salakhetdinov Shamil
mcp2004 at mail.ru
Wed Aug 8 05:20:28 CDT 2012
Hi Hans --
I do use TDD (as far as I understand it) for my customers .NET/C#/VB.NET development.
I do use NUnit to implement TDD tests.
To make clear: I do not use (yet) tools as NMock so "TDD purists" could say I do not use TDD at all.
Nor I use DI and tools like Autofac (http://code.google.com/p/autofac/) or Unity (http://unity.codeplex.com/) (but I do plan to start using them... somewhere in the (near) future...)
I'm usually trying to get all the base code (unit tests) and functionality (integration etc. tests) tested in automated way up till the level of calls coming from GUI or automation programs/scripts.
Usually but not always. It depends on project deadlines and funding.
GUI workflow is tested manually against specs both on my and on customers (UAT) side.
In principle GUI testing can be also automated but as my own practice shows custom GUI testing generic automation needs additional investments, which my customers don't have.
So I'm expecting to have GUI automation implemented for my customers projects together with TDD when "big boys" will get their tools released for technologies as http://en.wikipedia.org/wiki/Microsoft_UI_Automation - the tools, which will be affordable for myself/my customers...
Still, using my limited TDD approach I'm getting rather solid code base, which I'm able to refactor when needed without (almost) any fears to break existing functionality. I was never that confident with my VB6/VBA coding, which didn't have unit testing applied....
I have also tried to implement continuous integration (CI) using CruiseControl.NET (http://sourceforge.net/projects/ccnet/), it worked but again my practice showed that it was an overkill/there were no funding to keep CI working to successfully compete with others - so I do have my TDD tests "safety net" but I do not run all the tests before release - I do run only the tests created within current development cycle/phase and the ones covering codebase getting refactored...
Thank you.
-- Shamil
Wed, 8 Aug 2012 02:23:07 -0700 от Hans-Christian Andersen <hans.andersen at phulse.com>:
Oohh, a topic that approaches TDD. Fascinating. I'm curious to hear everyones opinion on this, because its an issue that typically divides developers and often in ways that show that its not entirely clear to some developers (albeit, not understanding the fundamental concepts and tenants of...) what the benefits are (to themselves as much as to the project).
Hans
On 2012-08-08, at 1:55 AM, Salakhetdinov Shamil wrote:
> Hi Ken --
>
> <<< * All of us have level 5 code -- we just don't know about it yet! However,
> if we find a bug, but can't fix it at the moment, we should at least
> document it and turn it into level 4.>>>
>
> Yes, 5D is usually acceptable.
> There is no *practically achievable* ways to turn any software at level 4C I suppose.
> I mean any released software we have done(/seen working somehow at customers' computers) have parts at levels 1-5, and 6-7, and even/often 8.
> The quality of released software will be the higher the less will be the probability to get issues at levels 5-7.
>
> The following quote is from "Code Simplicity" (http://www.codesimplicity.com/)
> "Law: The Law of Testing: The degree to which you know how your software behaves
> is the degree to which you have accurately tested it.
> Rule: Unless you’ve tried it, you don’t know that it works."
>
> Thank you.
> -- Shamil
> Tue, 7 Aug 2012 20:58:17 -0500 от Kenneth Ismert <kismert at gmail.com>:
>
>
>
> Here are some thoughts on software quality. What do you think?
>
>
> Code Quality: 1=Best, 9=Worst
> ------------------------------
> 1) Works, formal tests
> 2) Works, informal tests
> 3) Works, vetted but no tests
> 4) Fails in known, documented ways
> 5) Fails in unknown or undocumented circumstances
> 6) Fails by changing global state in a way that causes downstream failure
> of level 7 and 8 code
> 7) Fails by making assumptions about global state that are violated by code
> in level 6
> 8) Indeterminate, too complex, disorganized, or entangled to do any real
> vetting or testing
> 9) Unknown, first revision, untested
>
>
> Behavior on Error: A=Best, F=Worst
> -----------------------------------
> A) Fails immediately and unambiguously, and logs error
> B) Fails immediately and unambiguously
> C) Fails ambiguously
> D) Silently fails -- program terminates
> E) Silently fails and continues
> F) Silently fails and continues, causing downstream error
>
>
> Comments
> -------------
> * Obviously, we should all strive for 1A code, but few mortals produce
> exclusively at that level.
> * In the real world, writing code even down to level 4C can be acceptable.
> * All of us have level 5 code -- we just don't know about it yet! However,
> if we find a bug, but can't fix it at the moment, we should at least
> document it and turn it into level 4.
>
> And now, the bad levels:
> * 6, 7 and 8 all require code refactoring to fix
> * Note that 7 is worse than 6. If you must sin, sin boldly, but don't be
> naive about the state of your program
> * 8 is by far the most work, both to produce and fix
> * All code starts at 9, but a quick step-through and some critical
> re-reading can take it to level 3 -- at least until we find out it is a 5!
>
> And the bad error behavior:
> * C can often be fixed by adding more specific error information, or
> adding error handling code to routines that lack them
> * D, E and F are all serious, and should be addressed when encountered
> * People who write code at level 8 tend to rely on error levels E and F to
> try to hide their wrongdoing
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com