Port serial port test sources #15733
Conversation
This ports the test code essentially as-is. These need converted to xunit based tests and included in the test project as converted. I'll convert something in a subsequent check-in to set the example.
|
|
||
| public bool VerifyReadExisting(System.Text.Encoding encoding) | ||
| { | ||
| string text = "????????????4??????????????????,?11????????????????????????????????????????????????,????????????,??????????"; |
There was a problem hiding this comment.
Is this string something in unicode of some kind that hasn't come across right, or is that just GitHub?
There was a problem hiding this comment.
Oops, you're right. Needs to be converted to \unnnn
There was a problem hiding this comment.
Thanks. I'll follow up with my next change.
| // This is a regression test for Dev10 #511456, DevDiv Bugs #186131, and DevDiv Bugs #191753. | ||
| // Unplugged USB virtual serial port causes SerialPort object to crash application in finalizer thread. | ||
| // | ||
| // For this manual test, you will need a USB Serial adapater, probably one like this: |
There was a problem hiding this comment.
Are we going to try and retain these sort of manual tests within CoreFx?
There was a problem hiding this comment.
Yes, we have other cases of manual tests floating around other projects too (Console comes to mind). In this case, adding a skip to the attribute that you have to manually remove.
|
This is a veritable cathedral of serial port testing, I'm impressed. It does look to me like it mostly relies on real hardware to test against, even where that isn't explicitly called-out. Presumably it was documented somewhere what the h/w requirements were to run these tests - if so, can that document be brought across / published somewhere? |
If I find anything I'll bring it. As you can see these tests were mostly written over 13 years ago- finding documentation can be really tough as we went through many iterations of various collaborative tools (wikis, various Sharepoint versions, etc., etc.). Be pleasantly surprised if I find something. :) In any case, we need to set up a base class for the tests that we can use to provide properties to condition the tests based on specific hardware needs using |
|
I haven't gone through it in detail (only looking in GitHub at moment), but it's clear that tests are already able to define what they need in the way of hardware, and then they're run or not run depending on what specific hardware's available - we'll just have to work out a list of what runs for each hardware configuration, and then see if we're happy with any of the subsets. |
|
@JeremyKuhne I happened to clean up most of our internal SharePoints and wikis over the last few years and migrate them to http://clr - just search there. If it is not there, it is lost. |
|
Excellent! I volunteered to contribute to the tests/testing so I'll start digging in, after I check out the contributor guides since I'm brand new here |
This ports the test code essentially as-is. These need converted to xunit based tests and included in the test project as converted. I'll convert something in a subsequent check-in to set the example. Commit migrated from dotnet/corefx@c51e67a
This ports the test code essentially as-is. These need converted to
xunit based tests and included in the test project as converted.
I'll convert something in a subsequent check-in to set the example.
@ianhays, @karelz, @willdean, @msalsbery, @SWY1985
#984