Re: Unit Testing in .Net
- From: Jacques Bosch <jfbosch@xxxxxxxxx>
- To: programmingblind@xxxxxxxxxxxxx
- Date: Tue, 15 Feb 2011 21:03:21 +0200
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: <jfbosch@xxxxxxxxx>
> 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 <jfbosch@xxxxxxxxx>
> *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 <jfbosch@xxxxxxxxx>
>> *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 <jfbosch@xxxxxxxxx>
>>> *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:
