Skip to content

Added support for checking a file content result's textual contents. #24

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Sep 1, 2014
Merged

Conversation

AlexArchive
Copy link
Contributor

No description provided.

@AlexArchive
Copy link
Contributor Author

You mentioned in issue #3 that we should output the encoding in the error message. I want to ask you - what should the message be? I am struggling to think of a way to make the error message make sense especially in cases like this: http://i.imgur.com/6sgBTvO.png

@robdmoore
Copy link
Member

Interesting re: that screenshot.

I guess there is no way for us to know what encoding format was used so all we can do is output using the one they provided? So maybe that message would end up:

Expected file contents to be (UTF-8)"textual contents", but instead was (UTF-8)"#$%*#$G#$"

@robdmoore
Copy link
Member

Also, pomodoro - nice!

throw new ActionResultAssertionException(string.Format("Expected file to be of content type '{0}', but instead was given '{1}'.", contentType, fileResult.ContentType));
}

if (encoding == null) encoding = Encoding.UTF8;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer single line ifs to be indented so it's easy to see it's a block when scanning down the file

@robdmoore
Copy link
Member

I'm pretty happy with this; would you say it's good to merge?

I need to set up PR auto-builds for this project :P

@robdmoore
Copy link
Member

Ignore that build error. It actually passed.

Removed superflous using directives.
Moved test method into appropriate region.
Indented if statement (as per code review.)
Removed unintended whitespace between region.
Corrected test name.
Corrected errant test body formatting.
@AlexArchive
Copy link
Contributor Author

Expected file contents to be (UTF-8)"textual contents", but instead was (UTF-8)"#$%*#$G#$"

I think this is a good idea and I want to implement it but before I do, I think it might be worth discussing this a little more.

Ambiguity
I am concerned that this particular message might be interpreted in the wrong way. It is possible that the developer will interpret the specified encoding to be the actual encoding that we supposedly detected when in fact it is the encoding that (s)he told us to use. I suspect I am being pessimistic though - as somebody who understands what the message means unequivocally - I like it alot.

Encoding Name
We need to have some kind of mapping from the given Encoding object to a string that we can output in the error message.

Encoding Maps To
Encoding.UTF8 "UTF-8"
Encoding.UTF8 "UTF-7"
Encoding.ASCII "ASCII"
Encoding.BigEndianUnicode ?

What do you want to map Encoding.BigEndianUnicode to? The convenient option would be to map it to UTF-16BE:

Encoding Maps To
Encoding.BigEndianUnicode "UTF-16BE"

Could that be a bit confusing initially though? It is not too much of a leap from Unicode to UTF-16 or from BigEndianEncoding to BE but still. I would also say that outputting BigEndianEncoding in the error message is probably a bit too obtrusive.

Of course none of this will be valid if we pursue a different error message format or..

Leave the error message as is?
All I want to do is help the user fall into the pit of success 👌

As I explore how to do this I get the impression that it is always going to be a trade off and think it might be better to not "interfere" as it were. I want to hear your thoughts though. I do not have the foresight to say really.

If you want to roll with your proposed error message then I will implement it. Like I said, I like it a lot. Let me know!

@robdmoore
Copy link
Member

Really great points.

My gut feel is telling me to start with the simplest thing and then if someone complains try and make it more complex. Also, anyone who isn't using UTF-8 is probably doing something crazy and they should probably understand what's going on if there are encoding issues.

In terms of how to represent the encoding as a string I'd use the EncodingName property on the Encoding object passed in. Yes it's not the most succinct, but people are only starring at the error message when something is wrong and being a little more verbose is probably fine?

@AlexArchive
Copy link
Contributor Author

My gut feel is telling me to start with the simplest thing and then if someone complains try and make it more complex.

I am of the same opinion.

Would you agree that the simplest thing is to not print the encoding?

@robdmoore
Copy link
Member

Probably :)

AlexArchive added a commit that referenced this pull request Sep 1, 2014
Added support for checking a file content result's textual contents.
@AlexArchive AlexArchive merged commit 49b5b84 into TestStack:master Sep 1, 2014
@AlexArchive
Copy link
Contributor Author

It is like you say - we can revisit this when needed.

And here's to my first merge 🍻

@robdmoore
Copy link
Member

:)

Whenever you want the library deployed to nuget ping me and I can click the button on the ci server. Alternatively we can set up auto-deploy to nuget. Given this is a new feature it probably makes sense to bump the minor version number too (I'd like to follow semver from now on). The CI server uses GitVersion to version it. It auto-bumps patch for us, we can use NextVersion.txt to bump minor or major.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants