On Mon, 2009-02-23 at 10:01 +0100, Pascal Craponne wrote: > the idea is interesting, because I also have problems maintaining a VM > with all the databases. > Anyway I see several limitations: > - This will require to rewrite all current tests
Hence my suggestion that this would be /in addition to/, not a replacement for, the current tests. We want to keep the current tests as integration tests, to ensure that "end-to-end" functionality works. > - Making any small change (like the internal temporary objects naming) > would require to change all tests This is to be expected, somewhat. I'd consider it to be a feature, myself, so that the "externally visible" effects of an internal change are more noticeable. > - This makes any further optimization a pain. > As an example, I rewrote the SQL generation engine last spring/summer, > and even if the generated SQL is different is all ways from previous > engines, the existing tests helped me validating the engine. Also > (still my own story), some tests were complex, and I had no idea of > what it would look like in SQL (I'm not an SQL expert at all, and yes, > I rewrote an SQL generation engine :)), so until the engine worked I > had no idea of what tests should look like. It's not necessary to have the tests written and fully complete before the functionality is complete. In this case, I'd suggest doing the refactoring, then writing the tests to ensure that the functionality doesn't change in the future. (This also removes the "I don't know what the SQL should look like" issue, as you can just use the actual resulting SQL in the test, after you've written the functionality.) > - SQL is very different from one vendor to another. A good example is > how Skip() and Take() are handled in Oracle, SQL Server, and others. You'll notice that my approach solved this, by having a DataContractTest abstract base class (which has all the [Test] methods), and a MsSqlDataContextTest subclass which overrides DataContextTest methods. This allows subclasses to provide the actual SQL that's specific to that provider, without requiring that all databases accept the same SQL. > Regarding the tests, we could instead of a hard SQL string comparison > (which will totally break all tests after first change), use regular > expressions, so ignore internal names could be safely ignored, just > like maybe tables or columns names (without ignoring their > occurrence), whitespaces, comments, and so on? I'd be leery about using regular expressions, and would think that the current subclass approach would be sufficient. However, I wonder what sort of "internal names" would be present in the SQL that is being sent to the database.... > I also suggest to keep the current tests, but restructure them in real > projects with real directories (currently they are all in the same > folder, we could probably create new projets in new directories with > links to shared files, instead of having all test projects in one > folder). Please! :-) - Jon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
