Activity for Luc Feys
-
Luc Feys posted a comment on ticket #233
Forgot to mention, but cannot edit feature request anymore: * Default behavior would be to sort on all columns, in order to guarantee full backwards compatibility with current approach.
-
Allow PrepAndExpectedTestCase to sort only on filtered columns instead of all columns
-
Yes, that would be perfect for my use case. I was kind of reluctant to propose this, since at first it felt somehow like patchwork. But giving it some second thought, it could indeed be presented to the user as a proper feature that is easy to understand with proper documentation. I will create a Merge Request.
-
Hi Jeff, Thanks for your reply. My problem is that the 'expected' datasets are being read from Excel files from a legacy testing framework. And we should still be able to run the legacy tests, so adding a column to the expected dataset could be causing problems (will have to investigate). Also there are a lot of those legacy files, so - even if adding a column would be possible - I want avoid making changes to them, since this will result in a lot of work. I understand that you cannot break existing...
-
PrepAndExpectedTestCase should only sort on filtered columns
-
I have implemented all proposed modifications to the two commits, with the following remarks: Added some ITs for VerifyOperation in the first commit Only removed get|setExpectedDataSetAndVerifyTableDefinitionVerifier in the second commit, since the refactor of configureTest is required in order to make the setter obsolete Some additional thoughts/questions: Why are some of the methods in VerifyOperation 'public' (like applyColumnFilters, loadTableDataFromDataSet, ...). They seem pretty generally...
-
I have implemented all proposed modifications to the two commits, with the following remarks: Added some ITs for VerifyOperation in the first commit Only removed get|setExpectedDataSetAndVerifyTableDefinitionVerifier in the second commit, since the refactor of configureTest is required in order to make the setter obsolete Some additional thoughts/questions: Why are some of the methods in VerifyOperation 'public' (like applyColumnFilters, loadTableDataFromDataSet, ...). They seem pretty generally...
-
I have implemented all proposed modifications to the two commits, with the following remarks: Added some ITs for VerifyOperation in the first commit Only removed get|setExpectedDataSetAndVerifyTableDefinitionVerifier in the second commit, since the refactor of configureTest is required in order to make the setter obsolete Some additional thoughts/questions: Why are some of the methods in VerifyOperation 'public' (like applyColumnFilters, loadTableDataFromDataSet, ...). They seem pretty generally...
-
Will have a look at your remarks with regard to commit-1 and commit-2. Not sure about the 'all lines difference' for 'DefaultPrepAndExpectedTestCase' it shows indeed CRLF as line endings, but this is the same for all files I checkout. Git converts the line endings again when I commit. About the design for VerifyOperation: when I started on this, I did not really know what functionalities would be needed from the base Operation classes, so I started from AbstractOperation, but it turned out I did...
-
Will have a look at your remarks with regard to commit-1 and commit-2. Not sure about the 'all lines difference' for 'DefaultPrepAndExpectedTestCase' it shows indeed CRLF as line endings, but this is the same for all files I checkout. Git converts the line endings again when I commit. About the design for VerifyOperation: when I started on this, I did not really know what functionalities would be needed from the base Operation classes, so I started from AbstractOperation, but it turned out I did...
-
done.
-
Thanks for the feedback: I have updated my fork with latest changes from upstream (master) repository Have set the public getters and setters deprecated and added a getVerifyOperation getter to provide an alternative to retrieve the same information Have overloaded configureTest to allow specifying a ExpectedDataSetAndVerifyTableDefinitionVerifier Have added all above mentioned optimizations into a separate commit (I hope I understood your request correctly here) * Have aligned commit messages
-
No problem. Updated changes.xml, squashed and changed commit message.
-
I have created a merge request for this, on which I would appreciate some feedback before continuing work on it.
-
Extract database verification logic from PrepAndExpectedTestCase into separate VerifyOperation
-
I have code ready for this. Will create a merge request, but for some reason cannot access sourceforge through ssh today.
-
Extract TableVerification logic from PrepAndExpectedTestCase into a separate operation so it can be used with any testing approach
-
Done
-
Thanks for your feedback: Wildcard import was added by my IDE. Had not noticed. Thought I had reverted it to an expanded list of imports. Have pushed a fix for this. About the opposite condition check: since the behaviour of the default column filter might be database version dependent, I want to make sure the filter used in the test actually makes a difference. If at some point the behavior of the default filter would change, this test would fail and could be changed again to prove the new filter...
-
Thanks for your feedback: Wildcard import was added by my IDE. Had not noticed. Thought I had reverted it to an expanded list of imports. Have pushed a fix for this. About the opposite condition check: since the behaviour of the default column filter might be database version dependent, I want to make sure the filter used in the test actually makes a difference. If at some point the behavior of the default filter would change, this test would fail and could be changed again to prove the new filter...
-
I have a fix that works for me. Created a merge request.
-
Suggeste fix for #315 with regard to custom identity insert filter
-
OK. Had a look at it. Seems like there is already a test for this feature, which actually fails if it is activated. But currently it is disabled in the mssql41 profile because IDENTITY_INSERT is added to the list of unsupported features. Which is why this went unnoticed so far. So I will try to come up with a fix.
-
Wondering if there is any update on this? This issue already seems quite old, but I still ran into it today with DbUnit version 2.5.4 and 2.6. Is anybody aware of a workaround? Because the default IdentityColumnFilter does not work for me. Would like to try the extended one or write my own if needed.
-
Wondering if there is any update on this? This issue already seems quite old, but I still ran into it today with DbUnit version 2.5.4 and 2.6. Is anybody aware of a workaround? Because the default IdentityColumnFilter does not work. Would like to try the extended one or write my own if needed.
1
