Re: Unit Testing in .Net
- From: "RicksPlace" <ofbgmail@xxxxxxxxx>
- To: <programmingblind@xxxxxxxxxxxxx>
- Date: Tue, 15 Feb 2011 15:09:47 -0500
Hi Again: I would agree that it could be pretty powerful. If used correctly it
would provide the outtermost framework for an application which could be used
to ensure integrity throughout the LifeCycle. No problems here. My applications
are usually less than a dozen windows and less than a few thousand lines of
code including the auto-generated code provided by Microsoft. So, I would spend
more time developing a test plan and maintaining it than just developing the
small applications I usually work with. My modular approach usually gives me
good code independence with the most limited and judicial use of Globals. That
approach fits well into the OOP design concept and is perfect for applications
of say less than 20,000 lines of code or any application managed by a single
person. If I were working in a larger environment it would b on my list of job
skills since I would imagine it is used frequently there.
Later and thanks again for the overview.
Rick USA
----- Original Message -----
From: Jacques Bosch
To: programmingblind@xxxxxxxxxxxxx
Sent: Tuesday, February 15, 2011 2:03 PM
Subject: Re: Unit Testing in .Net
Hi R.
Actually, no, exactly not that.
TDD is part of the XP approach and suggests just enough architecture / design
up front to have a high-level strategy and to get started.
TDD in fact helps shape the application because it forces you to think about
what you are expecting out of the system.
It also allows for more flexibility and where you can go and what you can
change. If you have the security of a test bed of several hundred tests, then
it allows you to make changes and improvements to the system with greater
confidence as you won't be so worried that you are braking some other,
interdependent part of the system without knowing it.
Of course it is possible to write to many tests, and to write them in a bad
way that make any future system changes painful because it breaks so many
tests, if the intentionality was to change the way the system functions.
Doing TDD properly is a balance and an art, and just like programming itself,
it is not something that can be mastered in a short time, nor even understood
in terms of all it's power and potential.
I don't mind if people think that it is a waist of time or not a good
approach, and for some type of projects it might well be, as long as they have
taken the time to actually learn what it in tales and offers, and haven't just
glanced at it and formed an opinion. There is nothing like actually trying it.
And read a good book on it.
In my experience, programmers usually take a long time to be persuaded to try
it, but of all of those that have, I have yet to hear of one that ever dropped
it after.
It is like a drug, once you get into it, it gets addictive because it is so
cool!
Jacques
On Tue, Feb 15, 2011 at 4:00 PM, RicksPlace <ofbgmail@xxxxxxxxx> wrote:
Thanks Jacques:
I get it now...
So, you have a program to set various properties and, or, cause execution
paths to automatically execute so you can test the project at any time. This
sounds like a good option but would require extreme planning prior to doing any
coding but could be implemented modularlly as each module was planned out
prior to coding. That said, you have to be very, very detailed in the planning
process by defining all functions, subs variables and all that jazz prior to
coding the module. Also, if there is a change to any module for any reason you
would have to analyze, plan and change the Unit Test for that module or you
might not have a valid test downline. It would seem to add another layer of
complexity, time and a huge potential for likely runtime errors to crop up over
the months and years. That said, it sounds like a good Management tool for
large, extremely well defined and controlled projects.I have seen attempts,
mostely somewhat successful, doing something like this in the old days of
Mainframes by large Financial and Government entitys. Detailed System Analysis,
Planning and then detailed analysis of modular code with all variables named
and defined. Then distributing the various modules for coding by Programmer
Analysts and Programmers. Then the Analysts would Unit Test their modules
against predefined data to determine when they could be signed off as working
properly and the module added to the underlying Project at that point. Planning.
The problem we often had was that after a couple of years the test data
and the documentation was not always kept up to date and thus would become
counter productive if an attempt was made to use that process later in the
Project's lifecycle. Anyway, it would work if everyone did their job correctly
all the time but often hot fixes and Contractors make changes without going
through the entire process and things got out of sync. It doesn't matter since
it does not sound like something that I would use as a Lone Wolf programmer but
thanks for the overview and it sounds like you work for a larger company and
that is always a good thing.
See you later and thanks for the overview again.
Rick USA
----- Original Message -----
From: Jacques Bosch
To: programmingblind@xxxxxxxxxxxxx
Sent: Tuesday, February 15, 2011 8:41 AM
Subject: Re: Unit Testing in .Net
OK, the overload didn't show up it seems.
OK, unit testing is writing code to test your code. Test driven
development is writing the test code before you write the application code.
Say you have a Customer class in your application. There is a requirement
to add new functionality to the application to lock a customer down when their
payments or 2 months over due.
So you would first write a test, for the new functionality that doesn't
exist yet, run it to verify it breaks, then implement the application code
until your test passes.
Example:
[TestClass]
class TestCustomers
{
[TestMethod]
public void TestCustomerLockdown()
{
var customer = Repository.GetTestCustomer();
customer.Lockdown(""Really bad customer"");
Assert.IsTrue (customer.IsLockedDown);
Assert.AreEqual("Really bad customer", customer.LockdownReason);
}
}
You would use VS refactoring tools to generate the Lockdown() stub. At
first running the test will obviously fail. Then you go and implement the
Lockdown() method until your test passes.
The idea is that test should execute very quickly, you can make it a part
of the build step and you will get instant feedback on whether your code works
without always having to go and manually test it. Plus this obviously results
in a test bed for future regression testing and gives you confidence for future
refactoring.
It is a whole science, but that is a VERY brief start.
Jacques
On Tue, Feb 15, 2011 at 3:26 PM, RicksPlace <ofbgmail@xxxxxxxxx> wrote:
OK, you mean there might be allot of functionallity and, or, vendors
supplying Unit Testing software? I would guess that's what you mean. I just
would like the 50,000 foot view rather than a comprehensive analysis of
technicals. In other words, how do you use unit testing in say a Visual Studio
VWD or VB.net Application as you develop it as opposed to using the syntax
checker and built in test environment. Ya, just a quick overview is what I
would like so I get a general concept of what it is and the process used.
Thanks again:
Rick USA
----- Original Message -----
From: Jacques Bosch
To: programmingblind@xxxxxxxxxxxxx
Sent: Tuesday, February 15, 2011 8:07 AM
Subject: Re: Unit Testing in .Net
Sit back, and wait for the approaching information overload! :)
On Tue, Feb 15, 2011 at 3:01 PM, RicksPlace <ofbgmail@xxxxxxxxx>
wrote:
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
--
Jacques Bosch
Software Architecture and Development
Independent Contractor
Cell: +27 824711807 Fax: +27 86 504 4726
E-Mail: jfbosch@xxxxxxxxx
--
Jacques Bosch
Software Architecture and Development
Independent Contractor
Cell: +27 824711807 Fax: +27 86 504 4726
E-Mail: jfbosch@xxxxxxxxx
--
Jacques Bosch
Software Architecture and Development
Independent Contractor
Cell: +27 824711807 Fax: +27 86 504 4726
E-Mail: jfbosch@xxxxxxxxx
Other related posts:
