Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 01 2016 16:24
    jeremymeng synchronize #617
  • Apr 01 2016 14:28
    blairconrad commented #490
  • Apr 01 2016 11:07
    blairconrad commented #629
  • Mar 31 2016 14:14
    PascalK starred FakeItEasy/FakeItEasy
  • Mar 31 2016 13:00
    blairconrad commented #490
  • Mar 31 2016 12:48
    drauch commented #490
  • Mar 31 2016 10:57
    blairconrad commented #617
  • Mar 31 2016 10:52
    adamralph commented #617
  • Mar 31 2016 10:42
    blairconrad commented #617
  • Mar 31 2016 10:41
    blairconrad commented #617
  • Mar 31 2016 10:29
    adamralph commented #617
  • Mar 31 2016 09:27
    adamralph commented #637
  • Mar 31 2016 08:29
    cecilphillip commented #637
  • Mar 31 2016 06:27
    M-Zuber commented #637
  • Mar 31 2016 06:25
    thecodejunkie commented #637
  • Mar 31 2016 06:25
    adamralph commented #637
  • Mar 31 2016 06:24
    adamralph commented #637
  • Mar 31 2016 06:13
    adamralph labeled #637
  • Mar 31 2016 06:13
    adamralph labeled #637
  • Mar 31 2016 06:13
    adamralph assigned #637
Blair Conrad
@blairconrad
I'm more than content with whatever environment you use, since the AppVeyor build will test under an approved environment.
I'm sad that you're having a more difficult time, though.
Luke Marlin
@LukeMarlin
If I find a way through, I'll make sure to at least contribute with that :D
Blair Conrad
@blairconrad
Also, thanks for your efforts, @LukeMarlin!
Luke Marlin
@LukeMarlin
Hi @blairconrad . I've been able to dotnet restore, and I just ran dotnet test. I'm not trying your build scripts yet, I try to make small steps first
I noticed that you have some use of @ strings, with line feeds
All these tests fail on a Linux due to \r\n vs \n
Would that be an ok replacement for these tests:
var expectedMessage = string.Join(Environment.NewLine, new string[]{
"1:  Fake call 1",
"2:  Fake call 2",
"3:  Fake call 3",
"4:  Fake call 4",
"5:  Fake call 5",
"6:  Fake call 6",
"7:  Fake call 7",
"8:  Fake call 8",
"9:  Fake call 9",
"10: Fake call 10"});
instead of:
var expectedMessage =
@"1:  Fake call 1
2:  Fake call 2
3:  Fake call 3
4:  Fake call 4
5:  Fake call 5
6:  Fake call 6
7:  Fake call 7
8:  Fake call 8
9:  Fake call 9
10: Fake call 10";
Maybe there's better ways, like changing some setting somewhere in proj/sln/vscode, but I'm not aware of it
Blair Conrad
@blairconrad

Hi, @LukeMarlin. I'm glad dotnet test is running, even though it fails.
I am not sure about the best approach for updating these tests. Your proposed one looks like it would work, but we also use $@ strings which would make things more complicated.
It would be possible to add the Replace at the end of the $ string or $@ string rather than converting to use a Join, no?

Perhaps nicer would be to add a utility method in FakeItEasy.Tests.TestHelpers to do the conversion. Something like

var expectedMessage = Multiline(
@"1:  Fake call 1
2:  Fake call 2
3:  Fake call 3
4:  Fake call 4
5:  Fake call 5
6:  Fake call 6
7:  Fake call 7
8:  Fake call 8
9:  Fake call 9
10: Fake call 10");

And it could adust the line endings if needed.

Alternatively, I suppose we could have the repo adjust its line endings to be native when checked out, but that makes me nervous.

I assume you're doing this work in its own PR to support #1605, rather than as part of #1602.
Thomas Levesque
@thomaslevesque
Doesn't FluentAssertions have an option to ignore differences in line breaks?
If not, maybe it should!

I'm not trying your build scripts yet

I don't expect major difficulties here. The build.cmd just invokes dotnet, so it should be easy to translate to bash.

Blair Conrad
@blairconrad

Doesn't FluentAssertions have an option to ignore differences in line breaks?

I couldn't find it.

The build.cmd just invokes dotnet, so it should be easy to translate to bash.

It's true. Even tried this approach yesterday, but I had only a core 3.0 preview on my WSL, so things did not go well!

Hmm!
MatchEquivalentOf will ignore ends of lines and case, which is close. Looking to see if we can turn on only one of those switches!
Blair Conrad
@blairconrad
Nope. end-of-line ignoring is only available in MatchEquivalentOf (and NotMatchEquivalentOf). Which is nearly close enough.
Blair Conrad
@blairconrad
I don't see an easy way to inject the end-of-line-ignoring behaviour into arbitrary matchers (like Contains, Be, StartsWith, Match (if we don't want to introduce case-insensitivity).
We could in the interim add our own extensions for these behaviours, I suppose.
Thomas Levesque
@thomaslevesque

We could in the interim add our own extensions for these behaviours, I suppose.

Sounds good to me

Blair Conrad
@blairconrad
And probably the easiest for now would be to replace the incoming expectation with something that has matching line endings, unless you see something better.
Thomas Levesque
@thomaslevesque
The problem with verbatim strings is that the values will depend on the source file's line endings, which is different on Linux and Windows
Git's autocrlf probably comes into play here too
So I think the best approach is to avoid multiline verbatim strings, as they can't be correct on both Linux and Windows
Blair Conrad
@blairconrad
Indeed. You probably missed it in the scroll, but I'd suggested that we could adjust the repo to check out files with native line endings, but that makes me nervous I'd rather ...
Okay. What do you prefer? @LukeMarlin's approach of explicitly joining single-line strings?
Thomas Levesque
@thomaslevesque
(or maybe use them, but use a NormalizeLineEndings extension method to fix them)
Ah, yes, I missed it
I'm not too comfortable with this, though...
Blair Conrad
@blairconrad
Sometimes we do really want to compare multi-line output with an expected value. I think the multiline strings can help here. I would be more than happy with either a NormalizeLineEndings-type extension method or specialized FluentAssertion comparers. The latter is probably slightly cleaner as we don't have to pollute string, but it would just be in the tests, and I think not such a big deal.
Thomas Levesque
@thomaslevesque
Yes, that's probably better
The good news is, we don't have any verbatim string in the library itself
Blair Conrad
@blairconrad
That is good news!
Thomas Levesque
@thomaslevesque
We do have this, though, which looks suspicious. What becomes of the \r chars?
Blair Conrad
@blairconrad
I think they're lost! We should amend.
Thomas Levesque
@thomaslevesque
It could be safely replaced with a StringReader, which would take care of different line endings
Blair Conrad
@blairconrad
could it now? Cool.
Thomas Levesque
@thomaslevesque
I don't think they're lost, I think they're doubled
Blair Conrad
@blairconrad
Sorry, I misread. I think they're fine!
Thomas Levesque
@thomaslevesque
"xxx\r\nyyy" becomes [ "aaa\r", "bbb"] after split
Blair Conrad
@blairconrad
We remove \ns via split and then put them back!
yup, yup
Thomas Levesque
@thomaslevesque
Ah, no, you're right
Blair Conrad
@blairconrad
Good for us!
Thomas Levesque
@thomaslevesque
we're not using AppendLine
Blair Conrad
@blairconrad
Not this time!

Okay. Customized FluentAssertions it is, not unlike BeAnExceptionOfType.

@LukeMarlin, is this something you're comfortable with/interested in? I'd be happy to work on the change if not, but I realize it's blocking you, so maybe the timing works better if you investigate?
Whatever you prefer.