From: Gavin_King/Cirrus%<CI...@ci...> - 2002-02-01 01:17:38
|
>- Automated tests >Yes they are great ... for things that can be tested. But when you start >talking about developing GUI tools for Hibernate. How do you test those >automatically? It's really hard. I'm not saying lets not test them, but >we need to think about it if we are going to write the tests alongside >the actual code, as I want to get started quite soon on some of this. Yeah thats an entirely sane comment. I must admit I wasn't thinking so clearly about the toolset part of the project. For the engine the tests are _essential_....but automated tests of GUIs are arguably wrongheaded (A good test should encode a functional _requirement_, not a temporary decision about how user input is gathered.) I can think of two responses: 1. The correctness of the development tools is not really as critical, and anyway not as clearly defined ... so lets not bother with tests (Tests _can_ be a maintenence nightmare) 2. Perhaps its useful to expose a _programmatic_ interface to the tools which the GUI and tests and commandline client and possibly other frontends or applications use. I'm not at all convinced of the usefulness of this - its just a suggestion. Anyways. I think its clear we dont need to be too strict about requiring tests for the toolset. cool :) >I have seen a project that had automated tests that required the user to >simply go a view some output. Ok, not very automated, but as good as it >gets maybe? Yeah I'm quite happy with that myself. I always think you get 80% of the test effectiveness without _any_ assertions....just the test running is already a big thing. On the other hand, I think that for the persistence _engine_, we will always know extremely clearly the semantics we are trying to implement ... and we will know that those semantics (and the interface) can't change without breaking client applications. So the tests shouldn't be a maintenence prob. Okay anyways lets not get too bogged down in discussions of methodology. Everyone has strong opinions and usually what happens is that things decided a priori are totally irrelevant since what actually gets _followed_ is what the developers doing all the work are comfortable with. I'd rather see good code developed haphazardly than bad code done the "right way (tm)". However, it is a major aim of this project to generate pages and pages of quality documentation. Its such a missing aspect in soooo many other open source projects. >- Grouping, sum, count etc? >Just a thought. I actually needed to find out how many objects existed >(or how many rows in the table to put it crudely). I ended up just doing >a .size() on the collection results. Is there a better way? Do any other >OO query langs allow this sort of thing? Such things would be _ace_. At present though, the query language only returns persistent objects, never properties and its not clear what the sum of a set of Customers would be :) From my brief survey .... somebody please correct me if I'm wrong on this ... i think OQL is the only OO query language that has aggregate functions. The Hibernate query language is very much a work in progress (infancy?). >- Visual mapping (cocoabase) >In theory, it could really be powerful. Imagine JBuilder and WSAD >plugins as well! yeah thats what I was touching on with the GUI mapping generator. The one tool like that I ever used (VAJ's map+schema browsers) sucked horribly but its gotta be _possible_ to do something good. An eclipse plugin would be very very nice! >- MS SQL server and Informix I betcha SQL server works immediately by using the SybaseDialect. |