﻿<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <description><![CDATA[Comments for Simple Programming Tip #2 by Charlie Calvert]]></description>
    <title><![CDATA[Comments for Simple Programming Tip #2 by Charlie Calvert]]></title>
    <link>http://edn.embarcadero.com/article/30049</link>
    <!-- source: http://edn.embarcadero.com/article/30049/feed-->
    <dc:date>2009-07-09T13:41:54-07:00</dc:date>
    <item>
      <description><![CDATA[Hello Charlie,Thanks to a code generator I have authored a test vehicle for every programming task is effortlessly produced in seconds.  Additionally a package is created and every application begins as component with as a minimum of the following capabilities:User Login and Password VerificationDBMS &amp; SQL SupportHTML Help SupportCharts and GraphicsReport EnginesAce ReporterRaizeOrpheusADOMIDASThe DBMS operates on every available networking transport including TCP/IP and IPX/SPX.  BTW BDE is eliminated from this and all other BCS scenarios.The code generators output function on the first execution without further modifications.  Within seconds each task or projects has the six to nine weeks of lead work out of the way with no problem.  A file-naming convention was devised to clearly identify the functions of specific Delphi units.  A complete list of the files produced is available at:http://brookscomputingsystems.com/bcs/htm/prog/outmods.htm The full documentation for the tool is available at:http://brookscomputingsystems.com/bcs/htm/prog/abstract.htm Here is the link to install the code generator fully on your PC.http://brookscomputingsystems.com/bcs/htm/prog/install.htm There is also an associated workbench that forces the technicians to document, which application is being worked on and time stamps and elapsed times are calculated for all tasks.  The programmer does nothing to invoke this feature the application handles all the logic.  As the supervisor or team leader you simply run the report for the employee between specified data ranges and reach a determination.Documentation for the programmer’s workbench is also available at:http://brookscomputingsystems.com/bcs/htm/pwb/help/nad.chm A link to the workbench will be available at a later date.]]></description>
      <title><![CDATA[Simple Programming Tip #2 by Charlie Calvert]]></title>
      <managingEditor>
	 (Arch Brooks)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=36017</guid>
      <dc:date>2004-01-07T04:01:17-08:00</dc:date>
      <pubDate>2004-01-07T04:01:17-08:00</pubDate>
      <source url="http://edn.embarcadero.com/article/30049/feed">Comments for Simple Programming Tip #2 by Charlie Calvert</source>
    </item>
    <item>
      <description><![CDATA[tnx u program is very good please send for me to check up it]]></description>
      <title><![CDATA[Simple Programming Tip #2 by Charlie Calvert]]></title>
      <managingEditor>
	 (Majid Surany)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=35237</guid>
      <dc:date>2003-09-07T05:45:02-07:00</dc:date>
      <pubDate>2003-09-07T05:45:02-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/30049/feed">Comments for Simple Programming Tip #2 by Charlie Calvert</source>
    </item>
    <item>
      <description><![CDATA["First you need to write a test class for your not-yet-written class. Then you need to write a test class for your test class for your not-yet-written class. Then you need to write a test class for your test class for your test class for your not-yet-written class"---I don't find this to be the case. The two items - test code and production code, keep each other in check. If the test is wrong, there's no need for a meta-test to validate it -- it will simply fail. Debug the failure and either fix up the test if it's wrong or fix up the production code.Yes, it is conceivable to write a test that is wrong and still passes, nothing is perfect, but I've rarely run across this. Even if it occurred more frequently, the benefits of unit tests far outweigh the costs. I'd rather have 90% coverage than 0%.Chris MorrisDUnit co-Admin (the lesser)http://dunit.sf.net]]></description>
      <title><![CDATA[re: Simple Programming Tip #2 by Charlie Calvert]]></title>
      <managingEditor>
	 (Chris Morris)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=34803</guid>
      <dc:date>2003-06-17T06:46:14-07:00</dc:date>
      <pubDate>2003-06-17T06:46:14-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/30049/feed">Comments for Simple Programming Tip #2 by Charlie Calvert</source>
    </item>
    <item>
      <description><![CDATA[Sorry I didn't mention Bubelen and QTest. They both sound great, and I hope I can get some time to explore them in future articles. I definitely recommend that developers look into these and similar technologies. ]]></description>
      <title><![CDATA[re: Bubelen]]></title>
      <managingEditor>
	 (Charlie Calvert)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=34782</guid>
      <dc:date>2003-06-11T12:54:19-07:00</dc:date>
      <pubDate>2003-06-11T12:54:19-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/30049/feed">Comments for Simple Programming Tip #2 by Charlie Calvert</source>
    </item>
    <item>
      <description><![CDATA[Glad to see that some discussion was generated by my short piece. Some good points are made by both Paul and Kirk.Note that in the article, I said: "I still don't follow the rule to the letter, but I think it helps point us toward a very valuable set of programming practices." This is more or less what I hear Paul and Kirk saying. I personally do not advocate making a hard and fast rule of writing a test case for every method one creates, though I do not think the idea foolish. I think I was trying to spice up my article a bit by making my point as fervently as I could without ever quite advocating the "extreme" point of view.One issue to keep in mind when reading my article is that I was originally an English major, and so the section title "A Modest Proposal" is meant to be a literary reference that is a short hand way of saying: "Don't take me too literally". The short essay by Jonathon Swift called "A Modest Proposal" can be found here: http://art-bin.com/art/omodest.html. To summarize, Swift's tongue in cheek proposal is that a lot of trouble stemming from the poor in 18th century Ireland could be saved if the Irish people simply ate a large precentage of the children of the poor. Particularlly the males. Children are, after all, a good source of protein, and eating them would lead to smaller families, and smaller poor families would be less of a burden on the state. Obviously, Swift did not mean this message to be taken literally. I also did not mean to necessarily propose that people should write test cases for every method they write. I like test cases very, very much, but I meant the title of the section to help readers understand that they need not take me too literally if they had no such inclination. Thinking it over, I realize the reference might have been a bit obscure given the context.I did, however, mean to imply that doing a good deal of testing is in fact a good idea. (Don't make any analogies between this proposal and Swift's proposal! For now, just forget Swift!) I like tests a lot. They are definitely a very good idea. In fact, I don't necessarily think it would be bad to write test cases for every method, but I understand that the proposal is very extreme. Frankly, it is too extreme a proposal for my own tastes. I think simply writing lots of test cases would be sufficient. I definitely don't advocate writing tests for your tests. Kirk also touches on the whole subject of refactoring, and the important part that plays in development. As he points out, refactoring can break tests. I believe that in most cases test that become obsolete can easily be either updated, or simply deleted. I was thinking of using refactoring as a future topic for one of these articles. However, it won't hurt to point out at this stage that one advantage of having lots of tests is that you can run your tests to immediately see what code is and is not broken by your refactoring. This can be useful information.- Charlie]]></description>
      <title><![CDATA[re: Simple Programming Tip #2 by Charlie Calvert]]></title>
      <managingEditor>
	 (Charlie Calvert)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=34780</guid>
      <dc:date>2003-06-11T11:17:20-07:00</dc:date>
      <pubDate>2003-06-11T11:17:20-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/30049/feed">Comments for Simple Programming Tip #2 by Charlie Calvert</source>
    </item>
    <item>
      <description><![CDATA[Great article, Charlie!There is another framework for maintaining tests in Delphi. It's called "Bubelen" http://www.indyproject.org/Bubelen. It actually maintains so called "bubbles", these bubbles may be compared to "boxes" from the box- or unit-testing philosophy. The difference is that bubbles (or the code they are representing) are more flexible, that is profiling is one thing that is possible with them too. Bubelen provides an easy way to develop test cases (bubbles) in the RAD way.  Bubelen is an open sourced sub-project of the well known Indy project and is used for Indy's box testing. Bubelen is the successor of Boxter, which has been introduced by Chad Z. Hower and the Indy Pit Crew. Chad Z. Hower is Bubelen's Project Co-Coordinator.Olaf MonienBubelen Project Coordinator ]]></description>
      <title><![CDATA[Bubelen]]></title>
      <managingEditor>
	 (Olaf Monien)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=34770</guid>
      <dc:date>2003-06-10T12:08:39-07:00</dc:date>
      <pubDate>2003-06-10T12:08:39-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/30049/feed">Comments for Simple Programming Tip #2 by Charlie Calvert</source>
    </item>
    <item>
      <description><![CDATA[I agree that slavishly writing tests first doesn't make sense.  If you code a little, and radically change your approach due to a deeper understanding, your tests might become obsolete.  That said, I think it's good practice to write and run the tests before you declare a module done.  You are actually testing your mental model as well as your class and test unit, and you never know where those gremlins lurk.  The goal is overall productivity, and some simple experiments need not be tested at all.]]></description>
      <title><![CDATA[re: Simple Programming Tip #2 by Charlie Calvert]]></title>
      <managingEditor>
	 (Kirk Halgren)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=34764</guid>
      <dc:date>2003-06-09T18:45:24-07:00</dc:date>
      <pubDate>2003-06-09T18:45:24-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/30049/feed">Comments for Simple Programming Tip #2 by Charlie Calvert</source>
    </item>
    <item>
      <description><![CDATA[Great article.  But I disagree that writing test cases is the right place to start coding.  If we're new to OOP, then yeah maybe I can see that.  But if you've learned OOP properly, you should already be modularizing your classes down to the necessary levels of abstraction anyway. Writing your test cases first is what I call the "Escape from the Planet of the Apes Explanation of Time Travel" Theory of Coding:"First you need to write a test class for your not-yet-written class.  Then you need to write a test class for your test class for your not-yet-written class.  Then you need to write a test class for your test class for your test class for your not-yet-written class".  And so-on and so-on. ]]></description>
      <title><![CDATA[Simple Programming Tip #2 by Charlie Calvert]]></title>
      <managingEditor>
	 (paul culpepper)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=34762</guid>
      <dc:date>2003-06-09T12:05:45-07:00</dc:date>
      <pubDate>2003-06-09T12:05:45-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/30049/feed">Comments for Simple Programming Tip #2 by Charlie Calvert</source>
    </item>
    <item>
      <description><![CDATA[If you'd like to create your test cases form within the IDE, in a more drag and drop form, check out Qtest ( http://www.bigattichouse.com/ ) Its free, source is available, and it even does benchmarking, screenshots, and is threadsafe. Output can be by "Console" like DUnit,  requires no additional compiling of projects, and can output in CSV, XML and HTML.]]></description>
      <title><![CDATA[QTest]]></title>
      <managingEditor>
	 (Mike Johnson)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=34754</guid>
      <dc:date>2003-06-07T18:56:10-07:00</dc:date>
      <pubDate>2003-06-07T18:56:10-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/30049/feed">Comments for Simple Programming Tip #2 by Charlie Calvert</source>
    </item>
    <generator>Atom 1.0 XSLT Transform v1 (http://atom.geekhood.net)</generator>
  </channel>
</rss>