I'm trying to get familiar with unit testing with StructureMap, and am attempting to use the built-in auto mocker for Moq that appears to come with StructureMap. I installed the NuGet package using the directions
Install-Package StructureMap
and it installed and SM working fine. The repository clearly has the MoqAutoMocker code in it, but the StructureMap.AutoMocker.Moq namespace is nowhere to be found:
I've checked out several examples that make this seem very easy to do, but they're a couple years old and seem focused on previous versions of SM, but I'm hopeful there's just something I don't see yet:
http://joelabrahamsson.com/setting-expectations-with-structuremaps-moqautomocker/
http://evolutionarydeveloper.blogspot.com/2012/10/automock-with-structuremap-and-moq.html
Is there something obvious I'm missing here?
You'll need structuremap.automocking.moq package. Check this out: http://www.nuget.org/packages?q=structuremap.automocking
Related
Recently I've started to work with Maven JavaFX11 (openJFX11) and I noticed that there are many issues with javadoc in NetBeans. After some research I found that there is a bug with NetBeans that doesn't download the source+docs dependecies the right way (I mean it downloads it, but the next step to make it work is that you rename the source+docs files
issue & solution right here
But after I did that I noticed another docs issue and I have not found any similar topic on this so i dont know if it's just me or somebody have/had the same problem
When i type something like this:
private Label label;
label.[something...]
It only shows some of the docs.
It describes object Label the right way
After I type the dot, it only tells me about like 1/5 of the docs. Let me show you simple example.
And here is example of one that works
I looked into the javafx docs (.jar) and opened the Note.html and there ARE as the same things as in the docs they have on their websites, including all the methods, etc.
So... Dont you know, where the problem might be? I'm using the openJFX 11
It looks like you have encountered a known issue. See these NetBeans Bug Reports:
NETBEANS-1396 Maven: Downloaded javadoc / sources not attached to artifact with classifier.
NETBEANS-2197 Missing code completion and Javadocs in maven projects with classifier.
Also see these OpenJFX issues:
How to add javadoc in Netbeans #44
Attached Javadoc does not follow Maven convention #6
The fix is being implemented through a pull request for NetBeans 1396.
That fix is already included in NetBeans 11.3 which has a target release date of "January 15, 2020".
I seek a little help to wrap a package for meteor. It has always been my weakness on this framework. I know it is not difficult, I read tutorials and some articles like :
https://www.discovermeteor.com/blog/wrapping-npm-packages/
http://www.meteorpedia.com/read/Packaging_existing_Libraries
However I get lost in export and stuff, and it is time to understand !
I tried to wrap this package :
https://github.com/fians/Waves
(I knew one day I was going to not find the package already made by someone on atmosphere :()
So I wanted to do the thnings right, following guidelines made by dandv. I forked the repo, add the meteor packages with the files : export.js and package.js. Following the example of moment As you can see here :
https://github.com/Voyag3r/Waves
Finally, in my app, I created the local package folder with the meteor command : meteor create --package voyag3r:waves I tried to called the waves variable, bit it is not defined. I tried with and without a capital letter. (like in the source code waves.js). No, I tried with this.Waves instead of just Waves in export.js, neither.
There is something I do not understand with namespace and visibility I think, and errors are not displaying useful information this time. Is there someone to explain to me ? Because I would like to do a lot of other packages !
Thanks !
Glad to see that you read through those documents above, as they're quite helpful. However, I understand that it can be confusing to work through the details. Hopefully, I can assist you.
I recently finished packaging up a couple of libraries for Meteor, so you should take a look at those repositories as examples:
jspdf:core
jspdf:autotable
More specifically, take a look at the jspdf:core repository above and inspect the meteor-pre.js and meteor-post.js files for how to handle exporting variables:
meteor-pre.js
var window = {};
meteor-post.js
jsPDF = window.jsPDF;
Other important files include package.js and package.json, and of course autopublish.json, for integrating version updates with http://autopublish.meteor.com/, a fantastic tool written by Luca Mussi #splendido.
Additionally, I would recommend that you review the Official Meteor integration directly from 3rd party libraries discussion and ask #splendido or #dandv for assistance with reserving the namespace for this library.
This process has gone through rapid change over the last few months, and although not perfect, it's improving steadily. I'm encouraged to see that, like me, you want to assist the Meteor ecosystem.
It seems that Xunit no longer supports extending TraitAttributes. They have sealed the class.
There are also some other issues with Autofixture's plugin for AutoData() where we can inject random created data through an attribute. There are a few work around's for this, however I am attempting to evaluate this for a larger product overall. I liked the demo's since they could do small things like SQL, Excel, custom Attributes for category.
It seems there was more functionality before the changes. I have looked at the site and still see some of the features are returning and there isn't much information.
Is there a new set of functionality coming out? Or possibly a change that will allow us to recreate the older functionality in a new way? It seems the SQL and Excel have a work around, however I can't find any information about when the latest version will be compatible with "Autofixture with xUnit.net data theories" Nuget package. I really like what I have seen, though I can say I don't like breaking changes when I look at enterprise solutions. I cringe a little when I think about if I had this in place in an enterprise and I had made a lot of custom attributes, or used Moq and Autofixture to populate and now all my tests were broken. So I guess the other question is, does Xunit seem to change a lot with breaking changes? There is the other option of moving Xunit back a version. Though at some point I would need to know if these things would be fixed or if they were permanently removed, since I wouldn't want to spend time using functionality that is being removed.
Another is AutoFixtureMoqAutoDataAttribute that doesn't load without that side Nuget package. With the side nuget packages not being updated.
I guess the end question may be.. Does anyone know of any plans to get these features to work with the current version of xunit so that I can start implementing and then expect to do mass replaces later? Or are these permanently breaking changes where we shouldn't implement anything that is currently missing.
Thank you in advance.
Short answer
If you want to use xUnit.net 1.x with AutoFixture, use AutoFixture.Xunit.
If you want to use xUnit.net 2.x with AutoFixture, use AutoFixture.Xunit2.
Explanation
xUnit.net 2.0 introduced breaking changes, compared to xUnit.net 1.x (e.g. 1.9.2). For AutoFixture, we wanted to make sure that AutoFixture supports both. There are people who want to upgrade to xUnit.net 2.x as soon as possible, but there are also people who, for various reasons, will need to stay with xUnit.net 1.x for a while longer.
For the people who wanted or needed to stay with xUnit.net 1.x for the time being, we wanted to make sure that they'd still get all the benefits of various bug fixes and new features for the AutoFixture core, so we're maintaining two parallel (but feature complete) Glue Libraries for AutoFixture and xUnit.net.
As an example, we've just released AutoFixture 3.30.3, which addresses a defect in AutoFixture itself. This bug fix thus becomes available for both xUnit.net 1.x and 2.x users.
Thus, when you need to migrate from xUnit.net 1.x to xUnit.net 2.x, you should uninstall AutoFixture.Xunit and instead install AutoFixture.Xunit2. As far as I know, there should be feature parity between the two.
Traits
AutoFixture.Xunit and AutoFixture.Xunit2 don't use the [Trait] attribute, so I don't know exactly what you have in mind regarding this.
AutoMoq
Again, when it comes to AutoFixture.AutoMoq, it doesn't depend on xUnit.net, so I don't understand the question here as well. It sounds like a separate concern, so you may want to consider asking a separate question.
I know that FlexBuiler's refactoring engine can deal with updating variable names… But I can't figure out if it's possible to refactor at the package level.
For example, I want to move foo/a.as to foo/bar/a.as, and I want the package path to be updated (ie, from package foo to package foo.bar) and references to be updated accordingly.
Does FlexBuilder support this sort of refactoring? Or am I just doing something wrong?
No, it does not. Sorry. Your only option is to follow that with Ctrl-H, and swap out foo. with foo.bar.
The upcoming Flash Builder 4 will support Move refactoring to move a class into a different package. A public beta is available on Adobe Labs.
I ask this question in the hope of collecting all the incompatible changes/bugfixes in Flex 3.*, of which the maintainer of a Flex 2.0.1 application needs to be aware before upgrading. I'm thinking of issues of the following nature:
Bugs in 2.0.1 that had had some workaround, and have been fixed in 3.*, rendering the workaround not only useless but also erroneous.
Bugs introduced in 3.* that worked in 2.0.1, needing new workarounds.
Features that behave slightly differently (events, attributes, etc.).
Incompatible internal changes, that should not effect the progammer, unless they meddled a bit with the internal objects of the framework, like I did. :-)
Anything not fitting in any of these categories.
(I found several such issues, when I last tried this some time ago. Unfortunately I didn't take notes, and I forgot them since then, but I will update this post when I figure them out again. I reported one issue on the Adobe bug tracking site, it was unfortunately deferred.)
It would also be interesting to read about the advantages/drawbacks of such an upgrade. Are there any showstoppers?
here are some links that may help in your endeavors:
http://blogs.adobe.com/flexdoc/2008/02/migrating_from_flex_2_to_flex.html
http://blog.comtaste.com/2007/06/migrate_from_flex_2_to_flex_3.html
http://butterfliesandbugs.wordpress.com/category/flex-migration/
http://butterfliesandbugs.wordpress.com/2008/03/04/understanding-flex-3-migration-issues-part-i/
http://butterfliesandbugs.wordpress.com/2008/03/06/understanding-flex-3-migration-issues-part-ii/
http://butterfliesandbugs.wordpress.com/2008/03/16/understanding-flex-3-migration-issues-part-iii/
For the record, most of the migration problems from Flex 2 to 3 are minor, especially when compared to the problems of migrating from Flex 1.x to 2. I upgraded several applications with no problems at all. That being said, the above links should help note most of the problems you might run into.