Charles Hasegawa

Welcome Gojko!
After reading the first couple chapters (from the website), I realize that you are arguing for all the things that I have been advocating at my current position. We are making a move here at my company to become better at the requirements portion of change requests by implementing FitNesse as part of our development practices and trying to get the QA staff and other stakeholders (project managers, clients) involved early in the process.

That being said, would you say that the groups who would benefit the most from your book be the developers, or those folks who normally shy away from the software development until later in the traditional cycles?

Does this book assume any sort of knowledge background (other than java) or is it targeted to get people the information they need to get CI systems working in relative short order?

Thanks and welcome.

The biggest reasons I've stayed away from scripting languages within Java are the ones you'd probably guess - maintainability and pure maintenance.

If I introduce Groovy to my code, I force another technology upon all persons who are developing on that common code base. And while that might normally happen anyway with new API/libraries, its a bit harder with something that is conceptually different.

However, with Groovy being one of many technologies that is getting a lot of word of mouth these days (at least in my office), I'd like to know a bit more about it (best tool for the job and all that). My first concern with introducing a scripting language into my java code has to be maintenance. Will most common IDEs (specifically Eclipse) debug groovy script in java code?

Mark, the sad truth is you are in a tough spot. Not a lot of companies are looking to hire fresh college graduates. There are companies and jobs out there, but they are going to be hard to find. Your best bet is to hit the college job fairs and get your resume out.

The reality is that larger companies are off-shoring the entry level "grunt work / code monkey" jobs because its cheaper than hiring and training new grads. Smaller companies tend to offer internships (during which they get to do a "trial run" of the employee at a cheap rate) to prospects which lets them find good employees and "train" them cheaply before employing them.

Most job postings that want 2+ years of experience want just that - someone that can start coding right away, but is entry level enough not to demand crazy salaries. Training people is expensive and time consuming and there is no guarantee to the company that the employee will stay after the company pays to train them. By asking for that 2+ years, they hope to find people that only need to learn the domain, and can be productive relatively quickly.

Java certification may help you get interviews that you wouldn't get without them, but once you start working, are not going to be that helpful (unless for some reason your employer places value in them). A certification might indicate to a potential employer that you can do the coding, but again is really just helping to get your foot in the door.

(from the wiki - http://en.wikipedia.org/wiki/Integration_testing )
Integration testing (sometimes called Integration and Testing, abbreviated I&T) is the phase of software testing in which individual software modules are combined and tested as a group. It follows unit testing and precedes system testing.

Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing.

So now we're just being nit-picky. I'll argue its a unit test if I'm testing the DAO in isolation. The fact is, its coupled to a data store and I need to test its behavior to verify that my one piece of code (the DAO) works correctly. Before I can test if the business objects interact with the DAOs at an integration level, I need to know if my one piece of code works.
[ October 05, 2007: Message edited by: Charles Hasegawa ]

Originally posted by Lasse Koskela:

A unit test by definition does not touch an actual database. Instead, you unit test your DAOs in isolation from the database--usually against mock objects.

I'd argue that isn't that case. Testing your DAOs with mocks to test that the results are handled correctly is one test. I'd argue that testing that the DAO is asking for the correct information is just as important.
- Is the SQL formed correctly (ie, did we incorrectly set any params)?
- Did I write the SQL correctly - select from the correct table, join correctly, ask for the correct column names, etc.
- Does my SQL update the database correctly - does my sql leave the DB in the state I believe it should be left?

Even if you are using another layer - hibernate, JDO, ibatis, etc, these are still valid questions. In fact, your DAO may not even retrieve data or send values to the db. It may be that you are simply trying to kick off a stored procedure that needs to be run and you want to verify that the db state has changed after.

Another thought - lets say you did straight JDBC and never tested against the database. Months later, everything is working well, but you decided you want to introduce Hibernate. If you had a complete set of DAO tests that worked with an actual database, you'd know instantly, as you migrated each bit to hibernate, if you hadn't configured something correctly, or if you had done your Criteria based HSQLs correctly or not.

Mocks have their place in helping to isolate parts of your code, but you can't say that your DAOs are well tested if you never check the datastore's state.

I don't really understand the question...
The DAO is your last entry point between the raw data store (whether that is a DB or flat files or whatever), so how/why would you think to use mock objects to test the DAO?

I think the question is what do you mean by database testing?

Interactions with the DAO's are one test - ie do my objects use my DAO's appropriately and handle errors or bad data the way I expect. In most of these cases, the correct answer is mock object. Mock object will let you define the behaviors (ie I expect x going in to return 5 rows of data that will be a-b-c-d-e, so just give me that - OR - if I call this with a bad value I should get an exception, do I handle that correctly).

The DAO interaction with the database is another set of tests. Do my DAO's save the data correctly? Do they retrieve data correctly for given inputs? Are my transactions handled properly when there are problems? For these tests, DBUnit is one of your better choices. You set the initial state of the database and the expected state of the database as XML files. The framework handles the loading of the data and will also handle verification. It is a bit tedious writing the XML if you are testing on large datasets, but it beats most of the alternatives...

Show them that the cost of change and finding defects late in the development of a product is expensive.

The fact is, unless you are truly an advocate for TDD, its hard to explain the benefit to other devs, let alone the people managing the projects and money. The fact is, with a good suite of tests, making changes to the code is usually painless, because you know if things have broken right away, instead of trying to guess whether the changes work. When you are fixing bugs, you can determine immediately if you fixed the bug AND if you introduced any new ones. A smart manager will realize that his developers should spend time putting in tests NOW and release a quality product so that they can spend time in the future working on new work, rather than releasing buggy code that requires post-release resources to fix.

Not to get in the way of the author's response, but you might want to look into XMLUnit. XMLUnit is an extension to JUnit that lets you validate XML. If you have a schema (XSD) or a DTD for your XML, that is your first check (that the XML generated validates). Assuming that your XML is "valid" you then use XML unit to verify that the data has been parsed/transformed correctly. You do this by comparing the generated XML against an expect XML result.

There is a pretty good article on this exact thing at developerWorks

Originally posted by Bill Peck:


Sorry about the blank post.

Regarding Charles' question . . . Say a person was learning Java, but had a decent grasp of programming and software development. How many years of experience, generally speaking, would it take to have even the slightest clue of understanding of Charles' question?

I apologize if that seems a bit ambiguous to anyone not familiar with the terms MF uses, or his article...
TDD = Test Driven Development
Stub (as it applies to test) = a class that is created (typically) to fulfill a type contract (like a class implementing an interface) yet really has very little to it other than signatures and one or two "implemented" methods.
Mock (as it applies to test) = another "fake" object that implements an interface and can mimic behaviors desirable to a tester.

Basically, as OOP has matured, so has (in some cases) the complexity of the objects we create (or in some cases like J2EE - forced to create). With that complexity, you optimal will try to create objects that are very specialized, but at some point you will reach critical mass and need to create something that ties everything together. Unit tests for the individual pieces are straight forward, but more complex objects are harder to nail down. By using mocks and/or stubs, a developer writing a test has control over what a certain object will do and how it will act, thus taking one "variable" out of the equation. What MF talks about is whether the goal of a unit test on this type of object should be to test the behavior of the object vs the state of the system. A "classic" TDD'er says, "I know the state before and all I care about is the state of the system after for various inputs". A "mockist" says that how everything interacts is equally important in complex systems (you still have to get the right answer of course).

So, going back to the question at hand - I'm curious about the author's opinion, as it gives some small insight to their general approach to testing.
[ September 24, 2007: Message edited by: Charles Hasegawa ]

Best guess to that ambiguous "stuff" - the class in question does not have a no-arg constructor.

Martin Fowler wrote an article about classic TDD'ers and "mockists". Which camp do you feel you fall into?

The long and the short of his article:

The big issue here is when to use a mock or other double...

The classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing. So a classical TDDer would use a real warehouse and a double for the mail service. The kind of double doesn't really matter that much.

A mockist TDD practitioner, however, will always use a mock for any object with interesting behavior. In this case for both the warehouse and the mail service...

The first thing to consider is the context. Are we thinking about an easy collaboration ... or an awkward one...? If it's an easy collaboration then the choice is simple. If I'm a classic TDDer I don't use a mock, stub or any kind of double. I use a real object and state verification. If I'm a mockist TDDer I use a mock and behavior verification. No decisions at all.

If it's an awkward collaboration, then there's no decision if I'm a mockist�I just use mocks and behavior verification. If I'm a classicist then I do have a choice, but it's not a big deal which one to use... The real issue is between classic and mockist TDD.

[edited to use a meaningful subject line - was "Question for Lasse Koskela"]
[ September 24, 2007: Message edited by: Jeanne Boyarsky ]

Its been a while since I've used MyEclipse. For a long time, the DB tools and JSP/XML editors really seperated this from the pack. What features / enhancements are planned to separate this from the Web Tools that are becoming available through the Eclipse foundation?

Try Cobertura - Cobertura is a free Java tool that calculates the percentage of code accessed by tests. It can be used to identify which parts of your Java program are lacking test coverage. It is based on jcoverage.

http://cobertura.sourceforge.net/