Skip to content
This repository has been archived by the owner on Feb 8, 2020. It is now read-only.

Added Diagnostic and Diagnosticf. #4

Merged
merged 3 commits into from
Jan 5, 2017
Merged

Conversation

tesujimath
Copy link
Contributor

@tesujimath tesujimath commented Jan 5, 2017

Resolves #3.

These produce diagnostic output, as defined by the TAP spec.

I thought it was worth having both, as otherwise my code tends to be littered with fmt.Sprintf() inside t.Diagnostic().

These produce diagnostic output, as defined by the TAP spec.
@wking
Copy link
Collaborator

wking commented Jan 5, 2017 via email

@tesujimath
Copy link
Contributor Author

OK, that's a good idea. Give me a few minutes ...

@wking
Copy link
Collaborator

wking commented Jan 5, 2017

What you have in f9cf6d7 looks good to me, but this still needs a Makefile entry.

@wking
Copy link
Collaborator

wking commented Jan 5, 2017

e740b6b looks good to me.

The only other thing I can think of would be to have test/diagnostic/main.go write the Diagnostic calls to an internal buffer and have a wrapper harness which compares that output with the expected value. You can do that since b2acfdc with:

func main() {
  buf := new(bytes.Buffer)
  t1 := tap.New()
  t1.Header(4)
  t2 := tap.New()
  t2.Writer = buf
  t2.Header(1)

  buf.Reset()
  t2.Diagnostic("expecting all to be well")
  t1.Ok(buf.String() == "# expecting all to be well\n", "Diagnostic correctly formats a single line")

  buf.Reset()
  t2.Diagnosticf("here's some perfectly magical output: %d %s 0x%X.", 6, "abracadabra", 28)
  t1.Ok(buf.String() == "# here's some perfectly magical output: 6 abracadabra 0x1C.\n", "Diagnosticf correctly formats a single line")

  buf.Reset()
  t2.Diagnostic("some\nmultiline\ntext\n")
  t1.Ok(buf.String() == "# some\n# multiline\n# text\n", "Diagnostic correctly formats multiple lines")

  buf.Reset()
  t2.Diagnosticf("%d lines\n%s multiline\ntext", 3, "more")
  t1.Ok(buf.String() == "# 3 lines\n# more multiline\n# text\n", "Diagnosticf correctly formats multiple lines")

  t2.Pass("all good")
}

@tesujimath
Copy link
Contributor Author

Hi, I don't think that's worth the effort, sorry. I hope you will take the pull request anyway. :-)

@wking
Copy link
Collaborator

wking commented Jan 5, 2017 via email

@mndrix mndrix merged commit e740b6b into mndrix:master Jan 5, 2017
mndrix added a commit that referenced this pull request Jan 5, 2017
To verify the changes in #4, I intentionally broke Diagnostic() by
prefixing lines with "!" instead of "#" but the tests still passed.
The spec[1] allows a test harness to silently ignore lines it doesn't
understand, so that behavior makes sense.

Red light green light testing[2] requires that our test be capable of
failing if something is broken.  This commit adds that by comparing
the actual output against our expected output.

Hat tip to @wking for suggesting to compare output[3].

1: http://testanything.org/tap-version-13-specification.html#anything-else
2: http://stackoverflow.com/a/404860/174463
3: #4 (comment)
mndrix added a commit that referenced this pull request Jan 5, 2017
Now that we have a function to generate diagnostic output, we don't
have to construct it manually.

See #4
@mndrix
Copy link
Owner

mndrix commented Jan 5, 2017

Thanks @tesujimath for the patches. Thanks @wking for the code review. I've merged this branch and made a couple follow-up commits (referenced above).

@tesujimath
Copy link
Contributor Author

You're welcome. Thanks for merging it.

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

Successfully merging this pull request may close these issues.

3 participants