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
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.

Sorry folks. Gotta run. Time to clean up and maybe hang some pegboard.
Thomas Levesque
@thomaslevesque
OK, see you later then
Luke Marlin
@LukeMarlin
An extension method on string in FakeItEasy.Tests.TestHelpers.StringAssertionExtensions that would check that string matches ignoring linefeed?
What would be the best way, replacing all /r/n with /n, the check that the resulting strings are equal, or going through them via a loop to avoid "duplicating" the strings?
Blair Conrad
@blairconrad
Oh, I wouldn't worry about duplicating the strings.
Maybe this is short-sighted of me, but I'd consider taking the expected value and replacing \r?\n with System.Environment.NewLine, then comparing.
Or I suppose \r\n|\r|\n with System.Environment.NewLine. Or is this even necessary? I've been out of the Mac game for a while. Bare \rs have gone out of fashion, right?
Ah. Seems we switched over about 19 years ago. Probably no need to worry about it then.
Luke Marlin
@LukeMarlin
Alright, looking at fluentextensions API then. Looks like vscode's intellisense doesn't want to work today so it will be fun
Blair Conrad
@blairconrad
Oh, sorry. I think you want the extensions on StringAssertions. That matches what we did with BeAnExceptionofType.
... and VS is not responding, so I'll be delayed in confirming!
Luke Marlin
@LukeMarlin
Yep I'm already ther$
there
I looked at BeAnExceptionOfType as mentionned
Blair Conrad
@blairconrad
:+1: