Issue #1645 Interface Support Mock Testing#2215
Conversation
While trying to add complex types to the test model for SelectExpandTests, I ran into an issue with EF where some existing tests failed due to EF's own EDM model validation. This was happening because it assumes the new complex type is actually an entity type, even though it doesn't have a key. My solution is just to factor out the EF-related tests into their own class, SelectExpandEFTests. This should allow the addition of complex types to the SelectExpandTests test model without breaking any of the existing tests.
In the spirit of TDD, I wrote a failing test before attempting to fix this issue: OData#196 Unfortunately, the fix looks more like a large and complex feature than just a simple bug fix, and I don't have bandwidth to take it on right now. However, the test may still be useful for the next person to make the attempt.
* Update ODL dependencies to 7.5.0
- Update package versions.
- Revert test workaround for the pending 7.5.0 release.
- Disable obsolete warnings for AggregateTransformationNode.Expressions introduced in v7.5.0
* Update dependencies on classic side and performance.sln.
* Adding support to entity set aggregations.
* Enable IN operator for $filter. Supported collections include paren-defined collections, property collections, and navigation properties. * Added test cases to accompany change.
* downgrade the newtonsoft.json version to 6.0.4 for classic * change the newtonsoft.json version in classic test
|
I do not have write access to the destination branch. the conflicts that are currently listed are a product of natural development and where not present at the time this was completed. I may not have the time available to address. |
marabooy
left a comment
There was a problem hiding this comment.
Looks good to me, I didn't find any apparent issues with backwards compatibility.
@kccarter76 Do let me know when you are ready to get this merged in and any help you require.
| } | ||
| } | ||
|
|
||
| namespace Microsoft.AspNet.OData.Test.Formatter.Interface |
There was a problem hiding this comment.
Split this to two namespaces for consistency.
There was a problem hiding this comment.
not sure about what you are asking here? been awhile since looking at this code.
There was a problem hiding this comment.
I think you are asking about the sut class version in a class namespace and the interface implementation in an interface namespace. is that correct?
There was a problem hiding this comment.
it might be best to split into two separate files to simplify reading the code base.
There was a problem hiding this comment.
I need more eyes on this, since I have been unable to resolve the issue with the unit tests not running. @marabooy, I have sent you a collaboration request. I have hit a road block and the work crews appear to be on a permanent coffee break.
…2362) * Enabling query validation EnableQuery before action execution * Adding test * Name updates. * Adding #if for NetCore tests * Adding code to throw BadRequest * Fixing issues * Fixing the public API file * Adding fixes for tests * Fixing generic type code * Adding support for ActionResult<> * Taking PR comments * Taking PR comments * Taking PR comment * Taking PR comments * Just retrying build
* Fix MergeIndividualAndBatchPreferences method for same Prefer headers case (bug with an unnecessary comma at the end of line) * Add test merging same Prefer header while processing batch. Co-authored-by: Tsar Nikolay <nsmirnov@ics.perm.ru>
|
to resolve the above conflicts, it would be best to collaborate. I am not sure what needs to be kept and merge what is needed to support the interface. EnableQueryAttribute was straight forward. however the others not so much. |
…Data#2397) * Moving request query data to HttpContext * Adding one more E2E test * Adding tests for parallelization check
|
@kccarter76 the BSL updates can be done by running the respective PublicApi tests and copying over the new file. |
|
I am missing code for RequestQueryData. I may need to merge/pull the current master into my github fork. okay my EnableQueryAttribute is really out of sync with the base master and when I try to create a pull request from webApi:master to kccarter76webapi:master. |
…aster # Conflicts: # src/Microsoft.AspNetCore.OData/EnableQueryAttribute.cs # test/UnitTest/Microsoft.AspNet.OData.Test/PublicApi/Microsoft.AspNet.OData.PublicApi.bsl # test/UnitTest/Microsoft.AspNetCore.OData.Test/PublicApi/Microsoft.AspNetCore.OData.PublicApi.bsl # test/UnitTest/Microsoft.AspNetCore.OData.Test/PublicApi/Microsoft.AspNetCore3x.OData.PublicApi.bsl
|
is this being addressed in the AspNet solution: Severity Code Description Project File Line Suppression State this exception is preventing me from updating 'Microsoft.AspNet.OData.PublicApi.bsl' Severity Code Description Project File Line Suppression State was able to git this worked around by not running code analysis. however, the x unit tests are not running again and the work around from before is not working. |
| Disabled = 2 | ||
| } | ||
|
|
||
| <<<<<<< HEAD |
There was a problem hiding this comment.
Kindly fix the merge result here. I will check with someone on the team to see what can be done to help.
There was a problem hiding this comment.
working on it, currently dealing with an issue where VS 2019 16.8 will not run unit tests on local machine. see tail end of microsoft/vstest#1220
| /// </summary> | ||
| [ODataQueryParameterBinding] | ||
| [NonValidatingParameterBinding] | ||
| public interface IODataQueryOptions |
There was a problem hiding this comment.
This is more of a discussion than feedback: I came into this review not really knowing what query options were, and saw that the purpose was to convert it to an interface for mocking. I wondered to myself "how many ways really are there to implement a set of options? won't that just be a data type with a bunch of data type properties? there should just be a constructor overload where anything that needs to be mocked can be set directly instead". Seeing this interface, though, I see the many methods that are useful for the query options. I'm wondering, though, if it makes sense to separate those two things out. In this case, I would think the ApplyTo overloads belong on some other type rather than the options themselves. Do you have any thoughts on this?
|
Any updates? |
|
Any updates @kccarter76 ? |
4c43a84 to
ddfd3dd
Compare

Issues
Feature enhancement resolves #1645
Description
added the ability to use an interface IODataQueryOptions as a parameter on a controller method.
Checklist (Uncheck if it is not completed)
Additional work necessary
feature needs to still be documented and the issue #1645 updated with Docs Needed.