Re: Unit Testing in .Net
- From: "RicksPlace" <ofbgmail@xxxxxxxxx>
- To: <programmingblind@xxxxxxxxxxxxx>
- Date: Tue, 15 Feb 2011 08:44:27 -0500
Hi Jim: I agree totally. If you are working for a big company the paperwork for
planning and testing grows exponentially as the size of the project and the
number of people increases. For me, I am either a lone wolf or work with a
couple of folks on a project. Therefore I just figure out a project and then
break it into functional features. Then I pseudo code the User Interface for
one of the features, break out a few modules to make it work and then code each
module, one at a time, testing each module as I go along. When done with the
modules I have a feature working in the project, Then I do the same for the
next feature and so on until they are all done. If I want to expand the project
later I just decide what I want done, figure out how to do it and then code and
test each module until the update to the project is done. Sometimes I document
each module well enough to write a tutorial as I did when developing the
StarTrek Website for a fellow over in Tazmania, it got pretty messed up since
he was never able to grasp the technicals but it got done enough and I learned
allot about detailed analysis of modules by having to document in great detail
each step along the way for him. Anyway, I always thought Unit Testing had
something to do with automated testing of projects by Management using some
third party software but I've never looked into it since I never had a reason
to use it. But, if others are using it I am just curious about how they are
using it, that is, to what end and if they are using it with something like
Visual Studio or any of the Express Modules, VB.net or VB.net etc...
It might be useful with a Website to check if it is still working correctly
when developed in something like a CMS environment where things can change
without the Webmaster's intent causing the change but, rather, some third
party, dynamically loaded module getting messed up.
Thanks for the heads up Jim and see you later.
Rick USA
----- Original Message -----
From: Homme, James
To: programmingblind@xxxxxxxxxxxxx
Sent: Tuesday, February 15, 2011 8:21 AM
Subject: RE: Unit Testing in .Net
Hi Rick,
I don't understand everything about this either, but it sounds like your
approach is similar, but the whole art and science is extremely complicated.
It's like a lot of things in my view, where paperwork can get in the way of
productivity. I could be way off base with that comment, though. I believe in
some sort of plan before coding.
Jim
Jim Homme,
Usability Services,
Phone: 412-544-1810. Skype: jim.homme
Internal recipients, Read my accessibility blog. Discuss accessibility here.
Accessibility Wiki: Breaking news and accessibility advice
From: programmingblind-bounce@xxxxxxxxxxxxx
[mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of RicksPlace
Sent: Tuesday, February 15, 2011 8:01 AM
To: programmingblind@xxxxxxxxxxxxx
Subject: Re: Unit Testing in .Net
Hi Guys: What is this Unit Testing all about? The way I always worked was to
develop a project in a modular fashon. I plan, design and then code and test
one module at a time so I know my modules are working before going on to the
next module. How is this diferent from Unit Testing? I see a bunch of software
out there for Unit Testing and it all sounds complicated but perhaps I don't
really understand, actually I really don't understand, what it is all about.
Later and thanks:
Rick USA
----- Original Message -----
From: Jacques Bosch
To: programmingblind@xxxxxxxxxxxxx
Sent: Tuesday, February 15, 2011 6:51 AM
Subject: Re: Unit Testing in .Net
>measure twice, cut once.
And not the fingers either!
On Tue, Feb 15, 2011 at 1:43 PM, Kerneels Roos <kerneels@xxxxxxxxx> wrote:
Wise words from a wise man!
On 2/15/2011 1:33 PM, Homme, James wrote:
Hi Kerneels,
I had a Wood Shop teacher who told me measure twice, cut once.
Jim
Jim Homme,
Usability Services,
Phone: 412-544-1810. Skype: jim.homme
Internal recipients, Read my accessibility blog. Discuss accessibility
here. Accessibility Wiki: Breaking news and accessibility advice
-----Original Message-----
From: programmingblind-bounce@xxxxxxxxxxxxx
[mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Kerneels Roos
Sent: Tuesday, February 15, 2011 2:27 AM
To: programmingblind@xxxxxxxxxxxxx
Subject: Re: Unit Testing in .Net
Hi Dave,
The more I read about it and try it for myself the more I can see the
value of unit testing. it looks however like something you need to do
from day one of the coding of a project. It's very hard to come in
afterwards and add tests to code that is suspect. I'm very impressed
with NUnit, but the GUI runner I don't find very accessible
unfortunately. Most frameworks seem to have a command line runner also,
so one can do that.
Apart from the May 2009 book "The Art of Unit Testing ", there's also a
seemingly seminal book on TDD from 2002 focussing on Java -- can't find
the details now unfortunately, the author is Ken Peck.
What I do realise is that , for years now I've been coding and then
testing while TDD is the other way around. The code then test approach
is more of a cowboy coder / hacker style which sutes the creative, risk
taking right brainers :-). To shift to the test then code approach might
take some time and effort.
Now that I think about it, TDD makes a lot of sense for VI or blind
folks. If used properly it can minimise the need for debuggers. Don't
know about you guys, but I don't particularly like using a debugger.
Forgive the rambling.
Kerneels
On 2/14/2011 6:00 AM, Dave wrote:
With that said, lots of people don't follow TDD or some variant
because it does take a lot more time. You also have to consider that
test code usually piles up *very* quickly. You could have a few
hundred lines of code and to thoroughly test it (i.e. if you used TDD,
or if you measure code coverage), you'll need triple that in test code
or more. Once you make any changes in the production code, you end up
spending lots of time making changes to the pile of test code.
Not to say that you shouldn't test thoroughly, but lots don't
(especially to the degree they should) for some valid reasons. If you
can pull it off, it certainly will give your users less headaches when
trying to use your products. It's one of those "open ended" problems;
there's reasonable points to stop writing tests, but never a "end" as
there's always some other condition you could try for an sufficiently
complex piece of software.
You also don't want to go down the road of testing user interface
components as it requires hooking deeply into OS level events (most
ironically, accessibility is useful here).
On 2/13/11, Kerneels Roos<kerneels@xxxxxxxxx> wrote:
Thanks Dave,
It is not so nice to come in afterwards and write tests for classes,
which I'm doing now to ensure everything works right, but I can imagine
a TDD approach could work very well indeed. As I understand it, TDD is
also core to XP (extreme programming).
For anything new I'm going to write tests before coding and also look
into TDD more formally. Once you know how to code and design algorithms
one should invest in some solid software engineering techniques and get
a good methodology to follow. I strongly believe it will save tons of
time and produce far better software if the project is anything larger
than a simple CRUD system.
I can't decide if the book "The Art of Unit Testing" is worth the $24 or
not though :-)
Regards
On 2/13/2011 8:55 AM, Dave wrote:
The general approach advocated by some is that of Test Driven Development.
I have to say that whatever I've written using this approach has been
far more robust when it comes to quality.
The .Net unit test frameworks of which NUnit is only one, all have
lots in common. Visual Studio comes with a unit test framework as
well and integrates the running of tests within VS itself. The actual
tool chosen is a personal choice -- if you like integration with VS
for example or something independent. What tool's UI do you like,
etc.
Basically, they all use .Net attributes to "markup" methods and
classes with metadata; think test name, test description, run time,
category, etc. Then, at runtime, the runner just via reflection grabs
all of the tests and invokes them programmatically.
As for TDD, if you're not familiar with it, I'd recommend looking it
up. Essentially, you write tests before actually even implementing
anything. The tests serve as a statement of what you expect to be
true. This obviously requires that you iron out what your class
interface should look like; this might not be the style you're used to
and something C++ developers are more acustomed to.
However, as you go along, you already have a set of validation tests
that verify that your stuff actually works without doing the tedious
pattern of compile, run, manually check if it works, and rinse/repeat.
On 2/11/11, Jacques Bosch<jfbosch@xxxxxxxxx> wrote:
I've had good success with NUnit.
On Fri, Feb 11, 2011 at 10:25 AM, Kerneels Roos<kerneels@xxxxxxxxx>
wrote:
Hi, I've investigated NUnit and it'the GUI is quite accessible with JFW.
Also interested in MBUnit / Galeo but haven't tested the GUI yet. Unit
testing seems like a brilliant way to develop better code and keep it
working while changing things.
Advantage of NUnit is that the syntax is XUnit compatible, so what you
learn there directly applies to a host of other unit test frameworks and
languages. The more advanced Galeo / MBUnit is also XUnit compatible
should
you need more power later on.
Could anyone recommend a good book on this topic / some comments of your
own experience? I hope unit testing isn't just an accademic ideal but
actually something that can be done economically.
I found this e-book (PDF, epub and mobiM):
http://www.manning.com/osherove/
but it's from 2009 and doesn't seem to cover Galeo.
Any comments most welcome!
Regards,
Kerneels
--
Kerneels Roos
Cell: +27 (0)82 309 1998
Skype: cornelis.roos
"There are only two kinds of programming languages in the world; those
everyone complains about, and those nobody uses."
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
--
Jacques Bosch
Software Architecture and Development
Independent Contractor
Cell: +27 824711807 Fax: +27 86 504 4726
E-Mail: jfbosch@xxxxxxxxx
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
--
Kerneels Roos
Cell: +27 (0)82 309 1998
Skype: cornelis.roos
"There are only two kinds of programming languages in the world; those
everyone complains about, and those nobody uses."
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
--
Kerneels Roos
Cell: +27 (0)82 309 1998
Skype: cornelis.roos
"There are only two kinds of programming languages in the world; those
everyone complains about, and those nobody uses."
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
This e-mail and any attachments to it are confidential and are intended
solely for use of the individual or entity to whom they are addressed. If you
have received this e-mail in error, please notify the sender immediately and
then delete it. If you are not the intended recipient, you must not keep, use,
disclose, copy or distribute this e-mail without the author's prior permission.
The views expressed in this e-mail message do not necessarily represent the
views of Highmark Inc., its subsidiaries, or affiliates.
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
--
Kerneels Roos
Cell: +27 (0)82 309 1998
Skype: cornelis.roos
"There are only two kinds of programming languages in the world; those
everyone complains about, and those nobody uses."
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
--
Jacques Bosch
Software Architecture and Development
Independent Contractor
Cell: +27 824711807 Fax: +27 86 504 4726
E-Mail: jfbosch@xxxxxxxxx
Other related posts:
