testdriven.com Wrangling quality out of chaos

Archive for January, 2004

Test-Driven .NET: Code blog

01.31.2004 · Posted in News

Jamie Cansdale writes:

I have recently put up a site that anyone into test driven development in C# may enjoy.  The idea is you edit, build and execute C# source code online against a fixed set of NUnit tests.  When your source builds and all tests pass, you are given the opportunity to post your entry to the Code Blog.  At the moment the tests are for a simple sorting algorithm.  I am looking for some more interesting challenges to put up.  If you have some suitable NUnit tests, please send them to me.
 
You can edit and run your tests here…
http://www.testdriven.net
 
The following feed will contain only C# source with NUnit tests that pass…
http://www.testdriven.net/rss.xml
 
You might find more information at my weblog here…
http://weblogs.asp.net/nunitaddin
 
Have fun, Jamie.

PS. If you can see a specific security vulnerability, I would be very grateful for some example code.

Combinatorial Test Services from IBM Alphaworks

01.29.2004 · Posted in News

The Combinatorial Test Services (CTS) is a software library for generation and manipulation of testing input data or configurations. CTS enables the user to generate small test suites with strong coverage properties, choose regression suites, and perform other useful operations for the creation of systematic software test plans.

Ralph Johnson on TDD

01.29.2004 · Posted in News

from [domaindrivendesign] yahoo group:

On Jan 29, 2004, at 4:04 AM, Johan Nilsson wrote:
> I was thinking that TDD:ers could make a neural network program for
> them. Just write the test and let the neural network fix the rest. It
> will be guided by compiler errors and green/red lights. Without any
> domain model, programming is pure text manipulation anyway, right?

Ralph Johnson’s answer:

I am amazed that people took this comment seriously. It was clearly a joke. He was poking fun at TDD. The fact that people took it seriously indicates that someone (me) should make a more direct attack on TDD.First, I think TDD is a great idea, and my programming has improved a lot since I started it. However, it is not the end-all and be-all of programming, and the people who advocate it (i.e., the XP crowd) over-sell it. It needs to be over-sold, because the state of the practice of testing is so wretched. The vast majority of programmers do no systematic testing. If they get convinced that TDD is a magic elixir that will radically change their life, they might start testing.

But TDD is not a magic elixir.
You are not going to get good programs by using a neural net to make the tests pass. The reason that TDD works is because programmers are intelligent and creative, and because they eventually develop a domain model. When programmers are stupid and lazy, TDD will fail, like anything else.

Developing good software is hard. It requires knowing about programming languages, algorithms, the problem domain, testing, design, documentation (at the very least, how to name things), how to communicate with other people, how to get along with other people. Any statement of the form "follow this practice and you will be successful" is wrong. Sometimes I can look at what someone is doing and tell them "if you follow this practice you will be more successful", but no advice is universally applicable, and no practice, even TDD, is a silver bullet.

This applies to domain modeling, of course. Most groups that decide to model their domain fail miserably. That is because they think that a domain model is a UML diagram, not a language. They don’t follow the advice of DDD to start with a language that is shared by developers and customers, and then to figure out how to make the program reflect that language. They think that they will produce the domain model, and then others, less enlightened, will use it.

We are more likely to be successful when we do not underestimate the problem.

-Ralph Johnson

Agitar: Developer Testing Process Automation Tool

01.28.2004 · Posted in Tools

Agitar is the first true automation tool of the developer testing process. It helps developers create and maintain unit tests for all their code, allows team leaders up-to-the-minute and unbiased insight into the state of their project, and gives QA and Build teams unprecedented control of the quality of the integrated product.

More information at: http://www.agitar.com/products/2003-000001-agitarintroduction.html

AntFit 1.1

01.28.2004 · Posted in Java

AntFit 1.1 has just been released.

Changes include:

1. useWiki parameter: If your html files don’t have a <wiki> tag, set this to false. Set to true by default for backwards compatibility.

2. fork parameter: forks a separate java process.

http://www.cmdev.com/antfit/

Test First: Query Engine

01.27.2004 · Posted in Links

Generally, when writing a query engine (for a database, e.g.), you’d start with a language, and then write a lexer and parser for that language, before writing code to evaluate the parsed query.

What happens if you try it test-first? Let’s find out.

Our goal is to implement a query processor that takes queries in the form of strings, and returns the records that match that query.

Author: Roger Lipscombe
Published: 2002
Language used: C++
link

TDD *is* about testing

01.27.2004 · Posted in Links

"I see two fundamentally different types of testing in an XP/TDD/Agile project. Acceptance testing and Unit testing. There’s no point in describing acceptance tests as driving the design but unit testing is commonly viewed as doing just that." — Jon Tirsen
link

Tags:

XTest: General test framework for Java-based products

01.24.2004 · Posted in Links

XTest is a testing framework primarily developed for testing NetBeans IDE, but flexible enough to be used in testing any other Java-based product. XTest is based on Ant, which means it allows users to use all ant’s tasks, including custom extensions written for Ant.

XTest consists of a set of utilities, templates, sample configurations and recommendations on how to build integrated, flexible and easy to use test environments.
link

Artima SuiteRunner Project: A Tool for Conformance and Unit Testing for Java APIs

01.24.2004 · Posted in Links

Artima SuiteRunner is a free open source testing toolkit for Java released under the Open Software License. You can use this tool with JUnit to run existing JUnit test suites, or standalone to create unit and conformance tests for Java APIs.

The three main advantages Artima SuiteRunner offers to JUnit users are reporters, runpaths, and recipe files. Existing JUnit users can use SuiteRunner to run their JUnit tests, which allows them to gain the benefits of reporters, runpaths, and recipe files while continuing to use their JUnit test cases.
link

DbUnit 2.0 released

01.23.2004 · Posted in Tools

DbUnit is a JUnit extension (also usable with Ant) targeted for database-driven projects that, among other things, puts your database into a known state between test runs.

Change history summary:

* Refreshed documentation.
* Now use SAX2 instead of Electric XML DOM parser. Streaming mode allows importing and exporting very large XML dataset.
* New configurable data type factory that enable support for more database vendors’ types.
* Database views support.
* New MS Excel dataset.

http://www.dbunit.org/

A Dozen Ways to Get the Testing Bug in the New Year

01.22.2004 · Posted in News

In this article, Mike Clark describes 12 practical ways to start writing tests, and keep writing tests, regardless of your development process.

From the author: "The first two techniques play off of things you’re probably already doing, so you don’t have to move too far out of your comfort zone. The next two challenge you to wade deeper into the pool to realize the benefits of test-driven development. The remaining techniques round out the regimen to keep you testing effectively all year. You’ll be well on your way to fulfilling your new year’s resolutions. Caution: contents have been known to be infectious!"

Read the article at http://today.java.net/pub/a/today/2004/01/22/DozenWays.html

Contents:
1. Let Your Computer Do the Boring Stuff
2. Stop Debugger Testing
3. Assert Your Expectations
4. Think of It as Design
5. Build Safety Nets
6. Learn by Checked Example
7. Corner Bugs
8. Expand Your Toolbox
9. Make It Part of Your Build Process
10. Buddy Up
11. Travel With a Guide
12. Practice, Practice, Practice

RSS feed

01.22.2004 · Posted in News

testdriven.com’s RSS feed includes both our latest news items and web links. To syndicate this site’s contents, you can either enter the RSS links appearing at the bottom-right of this page into your favorite aggregator, or use http://www.testdriven.com/rss.php?news=10&links=10 to combine both feeds.

If you have a xoops site and would also like to provide your users with syndication for the Web links module, instructions to implement this alternate RSS solution are provided [url=http://www.testdriven.com/modules/newbb/viewtopic.php?topic_id=562&forum=5]here[/url].

The Simplest Thing that Could Possibly Work

01.22.2004 · Posted in Links

Ward Cunningham talks with Bill Venners about complexity that empowers versus complexity that creates difficulty, simplicity as the shortest path to a solution, and coding the simplest thing when you’re stuck.

Authors: Ward Cunningham, Bill Venners
Published: January 19, 2004
link

Tags: