I am using zf-1.12 with phpunit 4.0 and dbunit package. I got some issues while running test cases. it was regarding to redeclaration of some dbunit classes
After doing some troubleshot i noticed that these classes are available within phpunit itself and some 'require_once' lines in zend_test component were re-including same dbunit extension classes. I commented the lines to resolve the issue but I also come to know that ZF1 only support phpunit 3.4 or lesser version. So now I have some questions.
Which version of phpunit i should use with zf-1.12 and what new feature I won't be able to use with older version of phpunit.
If I upgrade my code to ZF2 then what version of phpunit I would be able to use.
Please also let me know if there is better other way to unit test zf application than using phpunit.
Thanks
Which version of phpunit i should use with zf-1.12 and what new
feature I won't be able to use with older version of phpunit.
You said your research came up with phpunit 3.4 with zf 1.12. I don't think you will notice much difference, all the main asserts will be there.
If I upgrade my code to ZF2 then what version of phpunit I would be
able to use.
If this is an option, do it! Not just for a newer version of phpunit, but for a newer version Zend. Also you will be able to use composer to manage your dependencies.
Please also let me know if there is better other way to unit test zf
application than using phpunit.
Phpunit is the standard & recommended way. For mocking, you could use Mockery with phpunit.
However, as an alternative, you could use phpspec.
Related
I am new to moodle and I need to do an upgrade. I have several questions first:
I have to upgrade from 3.4 to 3.5 and then to 3.9. Would I have to install all custom/aditional modules to 3.5 or can I do it just on 3.9.
This might be a dumb question, but I want to make sure I don't give anything for granted. In other to know which are custom/aditional modules I just have to go to the plugins view in administration and just copy the plugins that are on the section aditional plugins, right?
Thanks in advance
In general, you can get away with not installing all the custom plugins in 3.5. It is, in theory, possible that a 3rd-party plugin would choose to clean up their older upgrade steps, in the same way that core code does (which is why you can't jump direct from 3.4 to 3.9). I can't remember of any occasion where I've been caught out by a plugin doing that (and I've prepared hundreds of upgrades for different customers over the years). Note: you will see messages about plugins 'missing from disk' during the 3.5 upgrade step, but those should be fixed when you add the plugins back to the 3.9 code.
The list of additional plugins contains all of the plugins that are not part of the core Moodle code. It won't tell you about any custom changes that have been made to core Moodle files, but if you have simply been installing plugins and not messing around with core files (which is true in almost all cases), then you should be able to rely on the list.
Hopefully it goes without saying that you should always take a full database and moodledata backup before you start the upgrade, just in case there are problems (but, in my experience, they are fairly rare with normal upgrades).
I changed the Gallio.NUnitAdapterLatest.plugin with a binding redirect to this : oldVersion="2.6.0.0-3.0.5813.39032".
I also overwrote tje previous dlls in the latest subfolder.
I changed all occurences in the config file to no avail.
I also debugged the source code but did not manage to make it take my dlls.
What itches me is "compatiblity" between 2.6.x and 3.0 of nunit since as I read it somewhere, this trick can only be done if compatibility between the two dlls are maintained, which I am not sure.
I compiled Gallio in X86, for a .Net 4 test project.
Any ideas ?
I very highly doubt that you will get NUnit 3.0 running under Gallio's adapter. NUnit 3 is a nearly complete rewrite and it's engine is not at all compatible with the 2.6 core.
In order to get it working, you will need to create a new NUnit3 adapter for Gallio. Since Gallio is a dead project, I wouldn't expend the effort. Gallio's test runner is nice, but why are you still using it to run NUnit tests?
I am using Autofac in a project that is being obfuscated using Dotfuscator. the dotfuscator fails saying it cannot find mscorlib version 2.0.5.0
Is there a way to tell Dotfuscator how to obfuscate Autofac with portable Dll?
Is Autofac team planning releasing autofac with reference to .NET 4.0?
Any other suggestions?
I don't know what version of Dotfuscator you're using, but it does seem that at least as of 4.9.9000 they "know" about Portable Class Libraries. If you aren't at that version and can't upgrade, you might need to contact Dotfuscator support to find out a solution. (Another question of similar nature also pointed to updating Dotfuscator as the answer.)
A similar sort of issue occurs with FxCop analysis and SecAnnotate. To get around those issues with those tools, you need to tell them to ignore version information on certain assemblies (like System.Core and mscorlib). You may need to use an option like that on Dotfuscator if such a thing exists.
PCL can also cause challenges on machines that don't have all the latest .NET patches. Make sure you're patched up.
There is no plan to release an Autofac tailored just to .NET 4.x Autofac is a Portable Class Library so it can support multiple platforms without conditional compilation, making for easier testing and development. It switched away from platform-specific builds as of 3.0 and there's no plan to go back.
If upgrading Dotfuscator and patching your machine doesn't fix the issue, your best bet is to find the Dotfuscator mechanism for ignoring assembly version.
Before updating phpunit everything was ok, function assertRedirectTo() worked as it should, but after updating it shows this error:
Declaration of Zend_Test_PHPUnit_Constraint_Redirect::evaluate() should be compatible with that of PHPUnit_Framework_Constraint::evaluate()
Can anybody explain what exactly happened?
Yes, I ran into this problem too two days ago. But on the unfortunetly Zend Framework 1.x is not going to support PHPunit 3.6 or higher :-(
So the best thing is that you go back to 3.5 which is the latest version Zend Framework supports.
Check this:
http://zendframework.com/issues/browse/ZF-11871
Here you can read they will proberly make ZF2 supporting 3.6:
http://zend-framework-community.634137.n4.nabble.com/Running-the-zend-unit-tests-with-the-phpunit-3-6-PHP-CodeCoverage-Filter-getInstance-problem-td4023996.html
Does anybody have successfully working module in DNN 6 with the Ajax Control Toolkit?
My modules stopped working when we migrated from DNN 5.x to to 6.x.
Modules compile without errors but I am getting client side script error:
'AjaxControlToolkit requires ASP.NET Ajax 4.0 scripts. Ensure the correct version of the scripts are referenced. If you are using an ASP.NET ScriptManager, switch to the ToolkitScriptManager in AjaxControlToolkit.dll'
Seems like this is conflict with Telerik's controls, according to information that I have found. But I didn't find any info how to fix it.
You should be able to use older versions of the ASP.NET AJAX Control Toolkit, but once they start requiring the ToolkitScriptManager, you're out of luck with DNN (though you'll be out of luck with any version of DNN, since there's not a way to override the type of ScriptManager it uses.
Starting with DNN 6, they use Telerik's RadScriptManager. Previously, you could modify the core code to switch out for the ToolkitScriptManager, but now switching out might cause other issues.
It could work together, but you'll need do some modifications to the core of DNN.
Here the list of things to do:
Check that you're using latest version of .Net 4.0 binaries of AjaxControlToolkit (I was able to let it work for DNN 6.0.1 with Telerik 2011.01.519 and ACT September 2011 v4.1.50927)
Check that in your web.config you have assembly binding redirects for System.Web.Extensions and System.Web.Extensions.Design to the version 4.0
Take DNN source package, find Library\Framework\AJAX.cs, locate method AddScriptManager, instantiation of RadScriptManager in it, for the version 6.0.1 look into line 54. Add one more property initializer:
EnableScriptCombine = false. Compile it (in Release configuration, of course), take DotNetNuke.dll and drop into your DNN installation.
You should be done.
Credits goes to Telerik support, despite it's stated there that it should work out of the box starting from 2010.1.625. Not sure, did I get them wrong, or they just reintroduced this bug.
P.S. DNN support promises to release version 6.1.0 in November with updated Telerik controls, which should fix this issue, at least on their opinion.
Just checked with nuke 6.1 and the last version of jaxcontroltoolkit - still the same error.
It looks like it's not supported anymore. Sad:(