The problem
I'm struggling to make my Fluent Validation RuleSet work, currently it doesn't, and I don't have any idea why is that happening, everything seems all right. I would like to somehow step into the code that performs the validation itself, but RuleSet lambdas are ExpressionTrees which doesn't provide even poor debugging experience.
The question
Is there a way to debug RuleSet logic to see what's happening inside RuleSets?
FluentValidation is open source, so theoretically you could download the code from the repo at https://github.com/JeremySkinner/FluentValidation and then load up the solution, reference it directly, then step through.
Hopefully this will get you where you need to be, but I'm sure someone here could help if you provided your rules and maybe some unit tests that show the failures.
The current version of FluentValidation allows you to unit test your validators by using the TestValidate extension method. There is also an async version available.
Calling this method, passing an object to validate, will return a TestValidationResult<> object which has 2 useful methods ShouldHaveValidationErrorFor and
ShouldNotHaveValidationErrorFor that can be used to check if tests passed or failed.
The documentation can be found here https://docs.fluentvalidation.net/en/latest/testing.html
There is no way to debug Fluent Validator code with Visual Studio tools.
You need to comment the specific part of code (RuleFor) that you want to test. Keep doing it until all rules are tested.
You can debug Fluent Validation a little bit. When the validator is injected you can debug into the constructor like this:
At least then you know your services are registered in DI.
If you have a Custom validator, you can put a breakpoint there as well and actually break when the validation is called.
RuleFor(x => x.InstallLocation.Address.StreetAddress)
.NotEmpty()
.Custom(InstalledAtPhysicalStreetAddress);
Related
I try to use JavaScript library visjs.org in Dart. I prepared ‘adapter’ code according examples on Dart site pub.dartlang.org/packages/js and github.com/google/chartjs.dart/blob/master/lib/chartjs.dart.
Also according basic use case example from http://visjs.org I prepare client dart code.
While code compiles without any errors and warnings nothing happens in browser, expected to see graph-tree.
What I did wrong or miss to do?
https://gist.github.com/EdSv/e274a4d12ad3491c383fb4fe76ee671e
The attribute #anonymous is meant to be used when the object you're describing doesn't actually exist in the JS library you're binding, and is only used as a plain old data object. By adding it to all of your objects, my guess is that dart is never attempting to create anything from the visjs library.
Try removing the #anonymous from your Network class and see if that has an effect. You will likely also need to make these abstract classes as well.
I'm starting to learn how to do test-driven development, and I'm working with Swift. I'm suppose to have a test which should fail then write the code needed to get it to pass. From my understanding the test should successfully run, just fail. However, in Swift, when I try to write a test that, say, checks the value of a object's specific attribute, if that class doesn't yet have such an attribute (because I'm suppose to write the test first before I create it for that class) I don't get a failing test, but instead a build error when attempting to build and run the test. The error is that the test is trying to access an attribute that doesn't exist for the given object. Am I going about this the wrong way? Or are these test build breaking errors suppose to be what I get when doing TDD in Swift? Thanks!
According to Uncle Bob's 3 Rules of Tdd:
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
(emphasis mine). So there is actually no need for "the test to successfully run" - compilation error is a fine excuse to write code :)
TDD is a great idea, but don't forget to apply some common sense. In a case like this, treat the build error as if it was a test failure. At some point you have to create the class and the attribute to get the code to build. Then, elaborate on your test to make it do something that fails, write the code that makes it pass, and continue.
Im using Im using Quartz.Net in a MVC application.
I have gotten it to work with triggering an easy jobb (just print some text to output window), but when trying to do more complex work like maintenance work for the database im getting an error and the maintenance work rolles back.
When using the class that implements the job for maintenance separately, that is outside of Quartz.net it works fine, but when using Quartz im getting following error:
"A first chance exception of type 'System.NullReferenceException' occurred in Unity.Mvc3.dll"
Any ideas?
When I said it worked separately I was using Execute with no parameter from a Controller action.
This answer might help you.
It's a simple implementation using MVC4 and Unity.
At the bottom of the answer you will find a sample project.
Hope it helps.
This is a (actually it is several) follow-up question to my previous question on F# Type Providers and Continuous Integration.
It seems to me that it would be a good idea to use the SqlDataConnection type provider as a compile-time check that the code/database integrity remains intact in feature-branch driven development; you would know at every commit/build that no changes have been made to the code that has not also been applied to the database, assuming that building the database is also a part of your CI process.
However, a couple of questions arise:
The name (as well as the location) of the config file is not the same at compile time as at runtime, e.g. app.config -> MyApp.exe.config, which will result in a runtime error if you try to use
SqlDataConnection<ConnectionStringName="DbConnection", ConfigFile="app.config">
(Actually, specifying ConfigFile="app.config" is not necessary, since it is the default value.)
The runtime error can be avoided by copying the app.config file to the output directory (there’s a setting for that), but that would result in having both an app.config and a MyApp.exe.config file in the output directory. Not very pretty. Adding a separate configuration file for type providers would be another solution, but imho that’s not very pretty either.
Question: Has anyone come up with a more elegant solution to this problem?
The next problem arises when you come to the build server. It is most likely that you don’t want to compile against the same database as you did while developing, thus requiring a different connection string. And yes, in production you’d need yet another one.
Question: How do you go about solving this in the most convenient way? Remember, the solution has to be a working part of a CI process!
This strategy would require generating the database on each build at the build server, probably from a baseline script with some feature/sprint update scripts.
Question: Has anyone tried this and how did it affect build times? If yes, how did you create this step?
At runtime you can use the GetDataContext overload that accepts a connection string. See here: Providing connection string to Linq-To-Sql data provider
I am familiar with the solution that #Gustavo proposes, but I’ve always felt that there is something fishy about it. Something about having to specify the connection string twice… However, when I once again got the same reply, I slowly started to realize that the answer must be correct, and that it’s me who’s thinking wrong. These are my conclusions:
The reply states that you can use the GetDataContext overload that accepts a connection string. If you change this to should, things become clearer, at least to me.
The thing is that I’ve been thinking of the class definition as both a compile-time directive and as a run-time variable, but even though this is possible, it is hardly a good idea. The default value of the ConfigFile argument is as we’ve already seen “app.config”, but that file doesn’t exist (with that name) at run-time, so it doesn’t make sense to try to use it, thus leaving GetDataContext as the only reasonable option. I suggest that you do this:
Keep your compile-time settings in a file called compilation.config (or whatever you prefer) and specify this file for usage in the class definition.
Use the GetDataContext overload that accepts a connection string for run-time resolution and specify this connection string in the app.config file.
You will end up with something looking like this:
type private dbSchema = SqlEntityConnection<ConnectionStringName="DbConnection", ConfigFile="compilation.config">
let private db = dbSchema.GetDataContext(ConfigurationManager.ConnectionStrings.["DbConnection"].ConnectionString)
Heck, this even supports the SRP; compile-time settings in one file and run-time settings in another!
Regarding the rest of my questions, I assume that the answer lies in some scripting in the Continuous Deployment pipeline. Still interested in other solutions though.
Firstly, I've done a build, I've done a clean, I've done a rebuild, of both the project and the solution, so that's not the problem.
When I change my model for some reason the intellisense (in fact, it's not just the intellisense as if I do a build it comes up with an error as well) doesn't work. I have a model under ViewData.Model.ContractCostCentre which exists. VS isn't picking this up, at all. Instead, it's referring to an old one which has since been deleted and replaced with the prior one, this is called ViewData.Model.ContractCCList. So in my view I'm having to iterate over a ViewData.Model.ContractCCList despite this not even existing in my *.dbml file.
This isn't the first time I've had this problem, it seems to happen quite often if I change my dbml file (and it's likely to change as we work on highly progressive systems which are always subject to change).
Any ideas?
can you look into your ????.designer.vb or .cs, depend which language you are using
if you don't see that file, show all file in solution
intellisense is using that file
Kezzer,
At the top of your View, there is part of a line of code that determines what model type the page uses. It should look something like this (my example is in c#):
Inherits="System.Web.Mvc.ViewPage<ViewData.Model.ContractCCList>"
Change it to look like this:
Inherits="System.Web.Mvc.ViewPage<ViewData.Model.ContractCostCentre>"