Someone has tried to do a virtual filesystem for ant, but the problem is the third party tools interfere. How can you predict what a WSDL2java compiler is going to produce, except by parsing the WSDL and knowing its XSD to java mappings?

Deployment is a separate problem; it is what I work on in the SmartFrog project. What we have there is a notion of preflight, where you do every check prior to actually deploying, and make sure that everything is good to go. Where preflight fails is in integrating run-time values. How do I know what IP address the socket will be given, except by opening it? That’s a value I pass on to the component that checks for the web page, so ensuring we bump into any firewall set up on the localhost. There’s no complete substitute for a live deployment.

-steve

Keep it up!

These express a lot of the reasons that Apache Maven (particularly maven 2) came into being:
- modules and submodules are a key concept of a maven build, as is dependency management.
- a standard build lifecycle is applied to all projects so that ‘package’ means the same thing everywhere, as does ‘install’ or ‘compile’ or ‘test’.
- reusable build infrastructure through plugins (that should be coded, tested, documented and shared/consumed like your other code)

I like the concept of being able to functional test a build - I believe the role here is to be able to easily verify that the output of the build matches a set of expected criteria (files produced, contents of the files, other changes made, etc).

I wouldn’t delve into unit testing a build myself, though being able to ‘dry run’ and do the above validations rather than perform a build and then discover it didn’t meet the criteria at the end would be an interesting thing to do.

Thinking about it further, I believe that people don’t consider build as part of their deliverables and they feel why they should spend time on it……

What makes it more important is your build files goes through changes like normal code does but in case of build it could be reducing the build cycle, adding new sub projects, changes dependencies etc. And most of the time people
when people do change the build it breaks some other part of the build system which could days to figure out.

Now that we have seen so many builds that sucks, we should totally come up with list “build smells” and a unit testing tool which will help them to refactor their builds.

- Tutorial: Well, at least the documentation has been much improved lately - see http://svn.process-one.net/contribs/trunk/eunit/doc/index.html

Thanks. That actually helps quite a bit.

- Tests in separate modules: Lately, I’ve added an implicit check for the existence of a module ‘m_tests’ if you tell EUnit to test module ‘m’. If found, all the tests in that module will be run as well. (Note, though, that tests placed in a separate module can’t test functions that are not exported, so you’ll always need the ability to have tests in the same module as the code.)

Great minds think alike, I guess. The only thing I’d like to add is I personally believe in white box testing. If your module has so much going on that you need to test a bunch of private functions, I take that as a tip that I need to refactor my design. That being said, I mostly program in Object Oriented languages, so I don’t have much experience bringing that to a functional point of view. Until I see something that changes that, though, I’m sticking with it. I do like that EUnit now supports what I’m saying, at least.

- Pattern matching tests: There are several good macros that can/should be used in preference to plain ‘P = Test’ pattern matching: both boolean asserts, the assertMatch macro, and assertions for checking exceptions. All of these give you much better error messages. (I’m not sure what you mean when you write “don’t like using macros specifically for assertions as it makes the failures hard to debug”, since the macros are there specifically to make good error reporting possible. Another thing with the EUnit macros is that they keep working even if the EUnit library modules are not available.)

To be honest, that was probably a crap statement to make. I wasn’t even commenting about EUnit, actually. What I SHOULD have said was when trying to use macros to test that my assertions failed correctly, I found THOSE macros hard to debug. I actually like the error messages EUnit provides. Method name and line number. Hard to go wrong, really.

Good luck with your hacking. You’re very welcome with more input on how EUnit could be improved.

Thanks. Now that I know where the manual is, I’ll take a second look.

- Tutorial: Well, at least the documentation has been much improved lately - see http://svn.process-one.net/contribs/trunk/eunit/doc/index.html

- Tests in separate modules: Lately, I’ve added an implicit check for the existence of a module ‘m_tests’ if you tell EUnit to test module ‘m’. If found, all the tests in that module will be run as well. (Note, though, that tests placed in a separate module can’t test functions that are not exported, so you’ll always need the ability to have tests in the same module as the code.)

- Pattern matching tests: There are several good macros that can/should be used in preference to plain ‘P = Test’ pattern matching: both boolean asserts, the assertMatch macro, and assertions for checking exceptions. All of these give you much better error messages. (I’m not sure what you mean when you write “don’t like using macros specifically for assertions as it makes the failures hard to debug”, since the macros are there specifically to make good error reporting possible. Another thing with the EUnit macros is that they keep working even if the EUnit library modules are not available.)

Anyway, I don’t want to discourage you from what you do. Your idea of using a behaviour declaration was interesting, and might be something that I’ll add to EUnit; if nothing else, it can work as a marker that shows that the module was compiled with unit testing enabled.

Good luck with your hacking. You’re very welcome with more input on how EUnit could be improved.

/Richard