Jared Richardson

Originally posted by zinc ster:
[QB]how can I ensure that I reasonably test such that I can find all/most of the bugs that exist? ... I'm just wondering if there are some tips to make sure that I don't miss cases when I test.
[QB]

My best tack on getting good test coverage is to use upper level tests that tries to copy how you expect your users to use you product. Here's a blog entry I wrote called Mock Client Testing. It talks about this topic directly.

It's not exactly what you are asking for but have you considered a Continuous Integration system like CruiseControl?

It runs your tests every time someone commits changed code and makes the results available via several interfaces, included a web page.

Here are a few CruiseControl links.
CC at SourceForge.
CC Jira Wiki
My Continuous Integration page

A CI system has the advantadge of not forgetting to run the tests like developers tend to do...

Michael Feathers blogged on the topic this week.

A Set of Unit Testing Rules

Originally posted by Lasse Koskela:
[QB]JUnit tests are unit tests. That means that each of your JUnit classes (classes that extend junit.framework.TestCase) is generally responsible for testing one class and one class only.

QB]

Don't forget that you can use the JUnit testing framework to do much more than just unit testing though. We use it for unit testing, functional testing as well as integration testing.

The same attributes that make it attractive for unit testing (lightweight, portable, fast) also make it great uppper level testing framework as well.

Originally posted by Tirthankar Dutta Chaudhuri:
hi ,
i have a class which contains many private functions which are called from a public function . The job that those functions fo is to get a xml file over http . Parse the data apply the business rules . The public fuction returns a list . How do write a junit test for that . The xml file is very big 20000 lines so to get a list formed manually is not possible . Can anyone suggest me some methodology to test it .
Thanks,
Tirthankar

Hi Tirthanakar,

I'm not sure I understand what the problem is. Are you at a loss as how to unit test the class? My preference is to write the test from the point of view of the classes who are calling your class.

You mentioned several other public methods called this private one. Call one of those and make sure the stream is correct.

If you need to deploy this to an app server to test it, do so. I always prefer to test against a live system if I can. You can use a Continuous Integration system to run your tests on a server if your desktop isn't properly configured. (I'd run them in both places myself.)

If you need to add additional routines to enable testing, do so. I mean small, thin wrappers. Equivalent to setters and getters for the private routine.

Also, archive a known XML file. Then test the results of processing the known file.

Am I missing something?

Hi all,

Thanks for the kind words Hari. There are three important things to bear in mind.

1) Not everyone will like every book. This is a given. It's OK that Rick doesn't like Ship It.

2) There are a few people who do like the book. Some are better known than Rick. http://www.jaredrichardson.net/quotes.html

3) There will always be people who derive their sense of self worth from how many arguments they can start. This is not unique to the internet. You can deprive them of that feeling of power by simply ignoring them.
[ August 06, 2005: Message edited by: Jared Richardson ]

Ilja makes a great point... don't introduce anything if it doesn't solve a problem your team has.

Don't use Agile because it's Agile. Use Agile if it solves one of your problems.

Originally posted by Peter Sin:
To conclude: What are the benefits of "Process" ? Please refers to "Ship It! A Practical Guide to Successful Software Projects". I just want to test the author debate technique.

You might want to look Continuous Intergration. CI requires (1) source code managment and (2) a scripted build. If your team doesn't use these two, you can set them up yourself on your desktop for a proof of concept.

Then you install CruiseControl, AntHill, Continuum, etc (any one of the many Continuous Integration systems available). Use your desktop if you can't get a space on another machine. You can provide CI reports, email notification (if appropriate) and constant compiles with a location for automated tests to run... and you haven't "changed" the way the developers work.

They still compile, they still commit their code, just like always, but now, from the CI machine, they get small quality notifications. The code was good, the code was bad, test X passed or test Y failed. Developers will begin to expect these notices and get in the habit of more frequent commits, because they know it's "safe".

CI adds a lot of benefits without forcing anyone to change the way they work outright... and it gets the smart people introduced to CI. That means they hit Martin Fowler's site for the CI paper, etc. This introduces them to a whole new community. You've gotten them thinking about Agile processes without having to preach Agile. Then when you do introduce ideas, it's not the first time they've heard of them.

Congratulations to the winners and thanks to everyone who took the time to hang out and talk with us. Will and I enjoyed the week very much!

Originally posted by Tony William:
Jared,

For my team, we have use a spreadsheet for logging all bugs and major events / comments. The log will have a no. assigned. We also have document for each problem fix (w/ ref. to the log no.), problem desc, details, changes and revised source files are included in the doc.

Is this good enough? Any other approaches that you can shared?

When at all possible I tend to try to use existing software instead of writing my own... check out the list of packages here and have a look at their pages. Bugzilla for instance is a free program that you can set up and see what their default fields are. But it does sound like you've got it covered pretty well.

quote:
--------------------------------------------------------------------------------
I'm in a company that supports products for years and decades... I wonder how something like 3x5s would attempt to handle that situation?
--------------------------------------------------------------------------------



Remember that the cards are just planning tokens. Once a feature is implemented, it is specified in much more detail by the customers Acceptance Tests. The cards aren't needed any longer.

I meant the 3x5s used for the bugs. Onced the bugs are fixed, do you have any type of artifact that is kept around?

First, thanks for the dialog! I almost didn't post my earlier message... the discussions so far have been so good I didn't want to ruin it! Thanks for the reply!

By the way, there are some interesting discussions at http://c2.com/cgi/wiki?CthreeProjectTerminated

I've never seen that wiki page before! Thanks! It does shed a bit of light on the situation.

I guess our experience is just significantly different. That's what makes this discussion so interesting, I guess...

There wouldn't be much of discussion otherwise, would there?

"RJ" = "Ron Jeffries"?

What about http://www.scissor.com/resources/teamroom/ and http://www.xp123.com/xplor/room-gallery/index.shtml ?

So much for being discrete. heh... Ron is an avid defender of 3x5s in a few of the mailing lists I frequent. He doesn't seem to think that a project with a bug database can possibly succeed.

Thanks for the gallery links too! I hadn't seen those. Many of the pictures do seem to be teams that do projects for other companies. I'm in a company that supports products for years and decades... I wonder how something like 3x5s would attempt to handle that situation?

As far as I know, the 3C project (where XP was invented) used index cards for 4 years.

So what are your thoughts on the 3C project? It was never finished, was cancelled, and the entire shop reverted to traditional software after the consultants left.

Here's a short quote from this page:

There is still debate as to whether or not C3, as it relates to XP, was a success or failure. While it is true that C3 never met its goals, XP did make a doomed system work. The project was incrementally working at the pace it set. The first goal of printing a check in three weeks was met. The next goal of paying 10,000 employees within a year was met. The project was cancelled after four years of using XP, but before XP was threatened with cancellation after just one year. A few questions that are unanswered are "How many user stories were left?" and "How long would those user stories have taken to implement?" It is possible that management simply didn't want to wait that long. It's also possible that XP just couldn't handle the project at all and was going to fail sooner or later. Since the project was cancelled, we'll never know.

DaimlerChrysler is now working on yet another payroll system. They are using traditional methods and software practices. They are even using PeopleSoft. I need to get fresh details but the reports I have now (7/31/04) indicate that they have a big team, the biggest and fastest servers, have worked on it for about two years, and have not paid a single person yet. Compare that to a thin team, obsolete mini computers, and 11 months to actually start paying people with C3. Payroll at a very old, very large company is not as easy as you think which is why C3 was considered a success. --DonWells

Here's a short quote from the marketing material for Extreme Programming Refactored: The Case Against XP.

The authors also examine C3, the first XP project, whose team (most of whom went on to get XP book deals shortly before C3�s cancellation) described themselves as "the best team on the face of the Earth".

My point is not that XP is bad, but I'd love to hear more about ~your~ experience with 3x5s.

Also, I've turned about a decent amount of software over the years, but I've never seen anyone who could actually have a "few" bugs a year. Have you been able to do that?

Or they could have a big sheet of paper on the wall listing the current issues, with developers striking out the ones they just fixed.

And when tech support wants a list of the bugs fixed in the last release? Do you just grab all the sheets of paper included the ones from six months ago that you "archived" in the closet and make a "master" listing?

These sorts of tricks seem like trivial contrived answers to real business problems. Have they ever worked for ~you~? Sure, for an internal payroll project, the XP guys at Chrysler didn't need to have release notes. We ship our software to customers who like to see a list of discovered issues, fixed issues and outstanding issues.

I'm not trying to attack you... you seem like a very smart guy with some great experience... but the 3x5 card issue is (from my point of view) ridiculous. I've never worked in a shop that worked this way and never heard of one outside of vague claims (from RJ).

The practical disadvantages I feel in this approach are:

- Analyzer and Designer are included in whole life cycle (3 Month). In any company they are less in number and also take more salary than developer.

- In iteration 1, developer may be free for some days and in later iteration i.e. 4, analyzer and designer may be free for some days...

Please comment..

If the developers and analysts are working side by side, your developers will over time start to learn about architecture. They will learn (by experiencing it and participating) why the analysts make their decisions. The analysts will hear first hand the objections to any impractical designs they create.

All in all it sounds like a great way to build a more solid product ~and~ cross train the analysts and the developers. After a few projects you might not even need to differentiate between the two anymore!