in

dotnet.org.za

South African .NET Developer Portal

IceCoder

David from Denmark on .NET and more
  • what datasource to use..

    I am developing a desktop booking system which will provide users with the ability to manage bookings,inventory, accounts etc. The booking can either come from the desktop application or from a online booking system. So there should be an ability to sync between the two systems. interfaces are not defined yet so I am open for all suggestions. As the desktop application will be not be used by power users I want to keep the concept as simple as possible. There will max be 10 bookings made a day!

    I am considering developing the whole thing xml based and use the file system for storage? Has anybody got some good suggestions please email on david@winslow.co.za

    Thanks in advance!

    David Winslow

  • where to buy desktops!

    Does anyone know good places to buy desktop machines... if so please drop me a mail on davidfromdenmark@hotmail.com thanks!!

  • How Test Driven Development proved itself in a big way!

    Roy Osherove is a cool guy! No doubt. Reading his blog post below though made me think that what he is describing is more system integration testing or customer testing than actual Unit Testing. As he mentioned his application consists of many layers and therefore changing your database schema should not inflict your business layer!

    So for your unit tests to act autonomously you need to ensure that your e.g. business layer unit test are independent from your data access layer.

    So you want to test that calling ‘deleteCustomer’ calls the data access layer with correct parameters (not caring if the data access layer are screwing it up). You would then have to stub out your db layer with either static or dynamic mocks.

    I suspect this is what Roy also did since only five tests failed, however its not that clear from the article. Point is you could change your database completely (e.g. to DB2) and assuming your business logic stays the same only the tests that access the database directly will fail. Just my 2 cents.

    How Test Driven Development proved itself in a big way!

    Over the past year or so I've been going around trying to tell people how and why test-driven development will help their development process. Its hard to convince people. It's actually still hard sometimes, even after people have had real-hands on experience (after attending one of my TDD workshops). Why? because its just too good to be true , sometimes. And being afraid of what to tell your boss matters too.
     
    So here's a good story you can tell around the camp fire. Today I've experienced one of the most gratifying results of writing unit tests. We have a system that is near production ready, which involves lots of layers, logic and data. Today we had to do one of the most scary things you can do to a system that is near production - change the indexes of most of your database tables, including some primary keys, then go through all the stored procedures and change them to fit this new schema. How scared would you be?
     
    Heres how it worked for us:
    • Downloaded CodeSmith (awesome application, that.)
    • Created a simple template for stored procedures against all db tables
    • Ran the script against the database - generating only DELETE procedures
    • Ran all the tests
    • 5 tests out of about 200 failed
    • We tweaked the procs a little by looking at the old database
    • Ran all the tests
    • All the tests were green
    • We continued the same process for Update and Select procedures.
    • It took 4 hours to complete this whole experience, with all the tests running in the end.
    Imagine doing this on your system today. Would you even consider it?
    This is agility in its truest form: The ability to make changes to the system when you need it. And knowing what breaks when you actually do it. And being able to fix it and know that you actually did fix it.
    I could easily say that the Unit Tests paid for themselves just from today's experience. not to mention the amount of time they have already saved thus far. I am now throughly convinced that Test-Driven development is one of the best ways to tackle, if not reduce, the amount of risk in today's average IT project.
     
    If you're all now thinking "we don't have time to incorporate the complete "Extreme Programming" process into our Dev team - you don't have too. the project I'm talking about is NOT doing full on XP. however, TDD is a big part of it, as well as customer on site and refactoring. Some pair programming was done in several parts of the project, but not all of it.
     
    I can certainly say that had we not had unit tests - we would be doing today "Prayer Programming" :)

  • Fitnesse.NET customer testing

    For those of you who have an interest in making customer tests I think Fitnesse is the best tool out there! Its a wiki too! still wrapped around Ward Cunninghams FIT Framework!

     

  • Home sweet home

    Time is getting closer to end of my contract here in Denmark. 15 September should be my last working day. Its has been a very cool experience and met lots of people that I will stay in contact with!

    Anyways looking forward to seeing my family and friends etc again and getting back into the swing of things is South Africa. First step though is to meet up with some of the boys in London this weekend to watch the boks kick some serious ass :-) Man I am excited about coming back!!

     

  • Channel 9 Guys

    I guess you guys already know them...if not check out the their site here. I found there videos quite informative and easy to digest :-)
  • 10 ways to make your code more testable

    good article on 10 ways to make your code more testable over on TheServerSide.NET,

    Enjoy :-)

     

  • Test Driven Development Webcast with Jim Newkirk

    If you interested in TDD this is interesting. Its a overview of Test Driven Development...

  • Hiring guidelines for small ISVs

    Very informative article here by SourceGear Founder. I Like the part about too much education is a "warning sign" lol

     

     

  • Mocks vs Stubs

    Martin Fowler wrote a great article about this here. Never knew there was a difference..now I do!

    The project I am working on got shares 1000 assemblies and 150 developers (10% of the Danish population is working on this project :-) Daccis   )Needless to say when one guy change a interface in our Core assemblies all stubs break because they do not implement the changed inferface. Thats why I believe that it is far better to use Interaction based tests and generate the object on the fly based on the interface. That way you dont suffer the consequences when a interface change (as long as you use that specific method ofcourse). Then again interfaces should not change...yeah right :-)  

    Happy Mocking / Stubbing.

     

  • Introducing myself Just Babble

    First of I would like to just say "wat up"  to all of you. I dont know most of you however I am looking forward to knowing you all once I get back to South Africa. My Name is (there go the camel casing again) David Winslow (ok valid this time). I am originally from Denmark, however got a (wonderful) South African mother, and a (also wonderful) Danish father. I lived most of my life in Denmark, however used to go to South Africa very often on holiday. For some reason I got the feeling SA was the most wonderful place to be :-). In 1996 my parents moved to SA and in 1998 my older brother moved there also.Now on one New years eve back in 1999 I happened to be in Capetown for a party with some danish friends of mine. And I met a girl (its always about a girl) by the name of Aislinn. Since that day I REALLY loved South Africa :-) some months later I moved here too. I was so lucky to get to Tech-Ed 2000 where I first was introduced to .NET. I convinced the company I worked for (HR-Focus) that .Net was the future and that we might as well start now (Beta 1) . So we started on converting their HR application for Parmalat..cool  <I am just babbling away...hope this site dont charge per word or something> Anyhow I posted a message on google for a ASP.NET usergroup in SA. Two guys replied, one being Racerx A.K.A  mr. Armand du Plessis. Obviously you all know hiim :-). From there I moved to some other companies, until I finally for reasons onknown ( I needed the cash ok!!)  moved to the U.K and later back to Denmark (yeahaah :-(   )   So I am counting every day until I am back in South Africa, cause I believe that this country is the most wonderful place to be. My reasons for postings on this site is to payback for some of the good tips I always pick up from this site. If I sometimes seems cooky or just plain wrong feel free to tell me. I think you are all great guys and hope that, as I have, will feel that we together are, once again raising the bar for .NET in South Africa.

    Now its Saturday night..its summer in Denmark,which means half naked girls, Please excuse me for cutting this post short...I am off and looking forward to hearing from you guys in the future :-)

     

    Best regards,

    David Winslow

  • TDD: Equals,== and Assertions

    So you finished your tests and green lights all over..good feeling, however how sure are you that your testscases tests what you think they test? And if they indeed test what you believe they tests did your tests test what they should have tested? ..and ok you get the point right ;-)

    So the key in understanding this is twofold. Understanding the underlying OO concepts and understanding how this is utilized by Nunits Assertion class.

    So first when you compare object to each other you can use different approaches like Equals and  ==.

    apple.Equals(banana); 

    apple == banana;

    Starting with equals. The normal scenario where not methods are overriden will actually mean that apple.Equals(banana) will equate to (no pun intended) object.Equals(object obj) which in effect means that its the object reference that will be compared.

    Now lets say that apple have overriden its equals method. this means that its now up to the apple to decide how to compare with others. This is essentially was Assertion.AssertEquals does. Will check for reference equality or if overriden take that specific types equal method. That is fairly straight forward. Just remember you cannot be gauranteed what you actually compare unless you dig into the code.

    Using == again in most cases will compare object references. However if you in apple create your own == operator and you use assertion.Assert(apple,apple1) to check this objects you get a interesting result. Lets say apple's == method compare the age of a apple.

    apple1 = apple2;

    apple2.Age += 5;

    //Test

    Assertion.AssertEquals(apple1,apple2);

    This should return false, however returns true!

    Reason is that the assertEquals(object obj, object obj1) will end up in this call.

    public static bool Equals(object objA, object objB)
    {
          if (objA == objB)
          {
                return true;
          }
          if ((objA == null) || (objB == null))
          {
                return false;
          }
          return objA.Equals(objB);
    }

    Remember that we created our own == method so we would expect that method to be called here..however it is not called. The == method we created will only be called when the specific type is "apple". As you can see the equals call casts the apple to type object.

    So the key here is to know that operators can never be overriden, however equals can. So if we instead of creating the == method created a Equals method our test will give us the result you would expect. Hope this made sense to you, and I should have made a code sample :-)

    So the conclusion here is to understand exactly how the assertions work in Nunit as this is your last chance to ensure that your code tests the things its supposed to. If you can't trust your tests..well then all hope is gone and bugs will start biting :-)

  • TDD: Testing Internal classes

    You might get into a situation where you will need to write a internal class only visible from inside the assembly its declared in. If you (like me) separate your code and your tests in separate assemblies you got mucho problemos. By linking in the .cs file it will actually be compiled together with your test classes and therefore possisble to test. In general it is good practice to link in the source code that you would like to test, as it makes it easier to stub/mock objects that is not the primary objects testet...

    TDD rocks :-)

     

  • IceCoder's Blog comeBack

    To those of you who know me....Hey Wassup!!

    To whose of who dont know me..Hey Wassup!!

    I am looking forward to starting blogging again...and please bare with me if my posts often is a bit off topic and my english is not delicious :-)

    here is a link to my home page www.winslow.co.za/david

    if you realised after looking at the site  that u did indeed know me please read line one again.

     

     

     

Powered by Community Server (Commercial Edition), by Telligent Systems