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.
Related
I have a lot of UI Automation JavaScript code which is no longer useable since support was dropped in Xcode.
I'm looking for any means possible to try an reuse as much of the code as possible.
I just wondered if there's is any sort of migration path or hack to make it useable ?
I haven't seen anything so far.
Well, I've waited enough for iOS QA Automation Engineers to share their professional view on the matter, but since none showed up, I'll give it a go.
First off, you are not alone. UI Automation support has been dropped since XCode 8 and a lot of other people had the same problem.
The main takeaway from all the materials I've read online is this:
The only version of Appium that will work with xcode 8 is 1.6.0. You can download the beta now. Instruments/UIAutomation have been removed and only Appium's XCUITest support will work moving forward.
Moving forward, the best document to get you started with your test case migration, or at least give you some helping tips is this one: Migrating your iOS tests from UIAutomation (iOS 9.3 and below) to XCUITest (iOS 9.3 and up) [UPDATED LINK].
The article covers some pretty hot topics considering your situation:
Element class name schema;
Page source;
Locator strategies (with xpath emphasis);
Dependencies, API differences, etc.
You will have to start using appium-xcuitest-driver instead of appium-ios-driver.
Installation & Setup:
Apart from the relevant info that you'll find on appium-xcuitest-driver's official GitHub repo, the bread and butter is here: Setting up iOS Real Devices Tests with XCUITest.
Getting started with a new framework/set of libs, or migrating from one tool-suite to another is always hard, but from past experiences, once you have a working setup and build your first test case, everything else will go smoothly afterwards.
Finally, I could pro-long the response, but the official documentation will always do a better job.
Hope is helps in any way, shape, or form. Cheers!
What's the difference between the AspNetCore.Mvc and AspNetCore.Mvc.Core NuGet packages? Is Mvc.Core just bare bones stuff while Mvc is an all-inclusive package? That's what I would guess from looking at the descriptions here and here but it's not totally clear.
see https://github.com/aspnet/Mvc/issues/4785
AspNetCore.Mvc has all the basic stuff already set for you
if you want to use AspNetCore.Mvc.Core you will have to configure them yourself
it seems wise to use AspNetCore.Mvc unless you KNOW you need AspNetCore.Mvc.Core
If you use .AddMvc() then you get a lot of "opinionated" features, e.g. what kind of app are you building, which formatters are registered and in what order, which application conventions are there by default.
If you use .AddMvcCore() ("and you know what you're doing) then the behavior of your application will be decided by your own opinions and not the built-in default opinions.
Are there breaking changes in Moment from version 2.1.0 to 2.13.0?
I just inherited a code base that is using the older version and want to know if there will be problems upgrading to 2.13 from 2.1. Unfortunately there are no JavaScript unit tests for our web app.
I can say that in general, moment follows SemVer, so there are no breaking API changes.
However you may find some behavioral changes, as various bugs have been fixed over the years. Some consider it a "breaking change" when they depended on a particular bug being exhibited and later the bug was fixed, or when a function was improved to be more semantically correct.
As an example, the string returned by moment.utc().format() used to include an offset of +00:00, and it now returns Z. This more closely conforms to the ISO8601 and RFC3339 specifications, so the previous implementation was considered a bug, and it has since been resolved. Most people were fine with this change, as either form should be accepted by all modern parsers, but a few folks complained that this broke their code because they were manually parsing the results via string manipulation, and expecting a numeric value for the offset. We don't consider this a breaking change because the API didn't change, and the resulting string was compliant with the spec both before and after the change - it's just more accurate semantically now.
There are a few miscellaneous other changes like this, and they are all referenced in the changelog. If you edit your question to show which features of moment you are using, then I might be able to provide more details.
I have this patch developed for mailman-2.1.13, and I would like to port it to mailman-2.1.15
I never did this before, so I'm asking for advices here. How would you go about this task ? Here are my thoughts on the subject :
I could search the 2.1.15 codebase for code segments corresponding to the patch, but I would miss any new part depending on the patched code.
I could look at the diff between 2.1.13 and 2.1.15 and search for parts conflicting with the patch, at the risk of drowning into the many changes between the versions
I could simply rewrite the patch but I would need to understand all the logic of the patched application, which could be quite long ...
Your advices are welcome !
The keywords for search are "rebase", "merge" and "conflict".
A conflict occurs when different parties make changes to the same document, and the system is unable to reconcile the changes. A user must resolve the conflict by combining the changes, or by selecting one change in favour of the other.
You would find that resolving conflicts (e.g. porting patch to newer version) is usually not trivial operation and cannot be done correctly without deep understanding of code you work with.
Really depends on the change in main code base from mailman-2.1.13 to mailman-2.1.15, but sometimes it is easier to rewrite patch from scratch, sometimes it is sufficient to merge changes from patch to new version and try to fix the conflicts/problems it makes.
I would start with finding out what was the original problem that patch wanted to solve and how it was solved. Then look to 2.1.15 code and find out if the original problem is still there and if it is possible to apply the patch directly (internals didn't change so much in meantime) or new approach must be applied.
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.