Testing for DataTablesParam ModelBinder #81
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This project is really useful (and thanks once again). I wrote the testing framework about a year ago, and the api has changed since then, and some updates are available should you chose to use them:
-As per the heading of this pull request, the DataTablesParam model binder is now tested. This seems a fundemental part of how this application works, and errors in this have caught me out a few times. It tests whichever is the default binder for the DataTablesParam type in the Examples project, which you may not like, and this could be adjusted to instantiating a new instance of DataTablesModelBinder instead, but it has usually been problems surrounding the ModelBinder dictionary (rather than the ModelBinder itself) which has caused me grief in the past.
-In order to facilitate testing, the DataTablesModelBinder uses the ModelBindingContext, rather than the querystring. I have not performance tested, but this may add a few milliseconds?
-The DataTablesParam instantiator now includes an overload to instantiate all the lists at the specified capacity. This could be considered a micro-optimisation, but, as the length of the 6 collections is always known before instantiation, it seems to make sense to use this data.
-the ExecuteParamsAndTransform, due to the API change, had become an exact repeat of the ExecuteParams function, subsequent to the change in API last year. This now adds an anonymous transform function, used in a similar way to production code
-the viewmodel was no longer used, and is removed
-A few changes to make the syntax cleaner