FakeItEasy/FakeItEasy

The easy mocking library for .NET - http://fakeiteasy.github.io

Thomas Levesque

@thomaslevesque

It should be possible to build for netfx on Linux, using the Microsoft.NETFramework.ReferenceAssemblies package. But it's not stable yet, so I'd rather not reference it until it is.

In the meantime, you can just remove the target frameworks you can't target on Linux, and just not commit the changes

Thomas Levesque

@thomaslevesque

I opened #1605 to address this

Luke Marlin

@LukeMarlin

Thanks, commented it

I thought of removing the frameworks, but I wasn't sure that would be fine for you guys. I'll try that tonight, I hope I'll be able to run the tests by replacing the target entirely

Thomas Levesque

@thomaslevesque

I wasn't sure that would be fine for you guys

It's fine if you don't commit it ;)

Luke Marlin

@LukeMarlin

Ofc, but maybe you'd rather have people work in an approved env to contribute. After all, visual studio 2017+ is listed as a requirement :)

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!

Blair Conrad

@blairconrad

https://twitter.com/fakeiteasyfx/status/1167387237933375488

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

Where communities thrive

People

Repo info

Activity