Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Blair Conrad
    @blairconrad
    -html path/to/file.html
    dagilleland
    @dagilleland
    Switched to v 2.3.1, but running dotnet xunit getting "No executable found matching command dotnet-xunit"
    (I've only added packages via NuGet in VS IDE)
    Wow - got the HTML file with that option spec you gave.
    :)
    Blair Conrad
    @blairconrad
    Oh. You added dotnet-xunit. Quick. I was just looking up the
    <DotNetCliToolReference Include="dotnet-xunit" Version="2.3.0-beta1-build3642" />
    ... is what I'd had at one point.
    dagilleland
    @dagilleland

    specifically ran

    packages\xunit.runner.console.2.4.0\tools\net462\xunit.console SpecPut\bin]Debug\SpecPut.dll -html results.html

    with these characeristics:

    • Run from command line of solution (which holds the packages and SpecPut project folder)
    • Using the .NET 4.6.2 build version for the project (hence the specific \net462\ part of the xunit.console runner's path)

    And voila! Good HTML output!

    Hopefully these notes in the glitter will help people trying to get the HTML report output.
    Blair Conrad
    @blairconrad
    hopefully
    Well done.
    Truthfully, I've been content with regular command-line output from my builds, but I understand the appeal of the HTML
    dagilleland
    @dagilleland
    The HTML is not for me (the dev), but for the client who benefits from seeing some sort of "progress report". What better progress report than HTML results of the latest build?
    Blair Conrad
    @blairconrad
    Understood!
    I'm mostly my own client, in that respect.
    I just took your instructions and applied them to one of my projects. With success! I didn't realize the xunit console runner was still viable!
    As far as getting the HTML or XML report from VS, I have no idea. I've only ever done it from the console. I think it's your best bet.
    Sorry I wasn't more help!
    dagilleland
    @dagilleland
    With some CI building, I hope to generate the report and put it in the documentation repo. Getting it from the console is fine, as that's where I was going to end up anyway - just was wondering about seeing it in VS IDE.
    Thanks for your help! You cut short what was turning into a grueling afternoon! :+1:
    Blair Conrad
    @blairconrad
    Ha. Glad to hear it. I hope you're somewhere in the western Americas. Otherwise a long afternoon indeed!
    dagilleland
    @dagilleland
    Edmonton, Alberta, Canada :flags:
    Blair Conrad
    @blairconrad
    Nice. I'm landing there in early September.
    dagilleland
    @dagilleland
    New job?
    Or holidays?
    Blair Conrad
    @blairconrad
    Taking a 2ish week vacation. Edmonton/Barrhead/Jasper/Banff/Drummheller/Brooks/Calgary.
    Gonna see me some mountains and dinosaurs!
    dagilleland
    @dagilleland
    Sweet! Wishing you a good holiday & refreshment!
    Blair Conrad
    @blairconrad
    Thanks! My wife has family in Edmonton, Barrhead, and Calgary as well, so a good time should be had.
    Happy xBehaving.
    Next time, swing by the FakeItEasy Gitter. The answers roll off my fingers a little better there. :wink:
    dagilleland
    @dagilleland
    Shall do!

    FYI @blairconrad - A little follow-up on what I'm generally trying to achieve:

    Following advice from a Greg Young video (circa 2011/12) on doing DDD tests with Event Sourcing, I'm looking at leveraging xbehave with patterns of .ToString() on Commands/Events to write lean but expressive tests that output nicely to HTML (see image below).

    2018-07-17_17-27-43.png
    Blair Conrad
    @blairconrad
    Nice!
    Adam Ralph
    @adamralph
    @dagilleland another thing you might find interesting is https://github.com/ursenzler/xbehavemarkdownreport
    Jason Wisener
    @jwisener
    hi with xbehave is there a central place one can determine if the test failed?
    I want to take a screenshot if any step has failed in the test.
    Adam Ralph
    @adamralph
    @jwisener that's really an xunit question. Ultimately, xbehave steps are run by the xunit infrastructure as individual tests. If xunit allows some method of plugging into that pipeline, and performing some kind of general action (such as taking a screenshot) when a test fails, then it should be possible. I recommend asking over in the xunit chat: https://xunit-slackin.herokuapp.com/
    if you ask over there, ping my username in the question so I get notified, and I'll chime in if required
    Anthony Truskinger
    @atruskie
    image.png

    Hey there, I'm new to xbehave and I wanted to ask a style question. The docs say ", it should never be necessary to write code outside of a step. If you ever find a need to do so, please let us know"; I've found a reason and I wanted to know what you thought.

    I've got a massive amount of data-oriented test-cases. While most of the test cases require most steps and assertions to run, some should fail. This logically led to using a if statement to test these two different branches, and violated the no writing code rule.

    The tests run and work how I'd like but from a style perspective, are there any problems with this?

    Thanks!
    Adam Ralph
    @adamralph
    @atruskie I would write two scenarios for this. One with data that parses, and one with data that doesn't
    Anthony Truskinger
    @atruskie

    @adamralph Thanks for the response. I thought about doing as you suggested but there are multiple attributes to be tested - the date example i showed is just the first case... then there's lat, lng, etc... Though that means I should probably think about factoring this into smaller chunks anyway. I think this feature xbehave/xbehave.net#17 would make it easier to factor these into smaller specifications.

    However, I have been using the branching, like above, and from a technical standpoint there doesn't seem to be any problems...

    Adam Ralph
    @adamralph
    @atruskie yeah, I guess it should work just fine. It just looks a little odd, since I've never seen branching of the steps before :-) But here's another idea: in the cases where test.DateParseable == false, why not make test.ExpectedDateTime = null? Then you can use Assert.Equal() for all cases.
    and in that case, I guess the test.DateParseable property may become redundant
    Anthony Truskinger
    @atruskie
    @adamralph that's a good idea, thanks
    Adam Ralph
    @adamralph
    @atruskie you're welcome. Thanks for raising the question.
    Christian Johansen
    @cjjohansen_twitter
    Has any one succeeded in using dotnet test for generating xbehave xml output to be used by xBehaveMarkdownReport?
    ive tried this dotnet test --test-adapter-path:. --logger:xunit;LogFilePath=markdown-report.xml
    but im not sure the generated xml is xBehave style