Comments (6)
Thanks for the report.
Looks like the main problem is, as you pointed out, that the report is constructed only after everything has been parsed. Your suggested solution appears to work, but I think there's an alternative way to fix this that doesn't involve the added complexity of running report
concurrently to parse
and communicating via a channel. Instead, we can merge the report
code into the parse
function. I.e. move the report builder initialization before the for
loop in parse
and call rb.ProcessEvent
at the same place where the events are added to the p.events
slice.
Another potential problem I found is that the package timestamp in the report builder only gets set when we encounter a summary line (in CreatePackage
), which is pretty much when the test has already completed. I'm not sure whether timestamp field was intended to contain the starting or ending timestamp of the testsuite, but I suspect it's the former. To fix this we'd have to modify the packageBuilder
to store the creation timestamp in newPackageBuilder
(which typically happens when we process the first event of a new package) and use that rather than the current timestamp in CreatePackage
.
If you're interested in fixing these, feel free to send some PR's. Otherwise I'm happy to make the change once I have some time.
from go-junit-report.
Thanks! I'll take a look at implementing it as you describe, that makes sense as well.
I'm not sure whether timestamp field was intended to contain the starting or ending timestamp of the testsuite, but I suspect it's the former. To fix this we'd have to modify the packageBuilder to store the creation timestamp in newPackageBuilder (which typically happens when we process the first event of a new package) and use that rather than the current timestamp in CreatePackage.
I suspect it's meant to be the start timestamp as well. This wasn't impacting for me, but it probably makes sense to address at the same time. I was thinking we could also use the timestamp function minus the duration. I think if it was based on the first event of a package the reported timestamps per test could be well before the test actually started. I might be misunderstanding the fields though!
from go-junit-report.
Hey @jstemmer, sorry for the extreme delay/lack of comms. Anyways I finally took the time to take a closer look at implement the suggested solution. PR up and it works great!
from go-junit-report.
@jstemmer, sorry for the extra ping -- I just wanted to see if you may have an opportunity to review and merge the change.
from go-junit-report.
No problem. I've been busy lately, so didn't get a chance to take a look until just now. Thanks for taking the time to fix this!
from go-junit-report.
Thanks, much appreciated and totally understand being busy -- took me 5 months to actually make the change 🤷♂️
from go-junit-report.
Related Issues (20)
- after I use "go test xxx 2>&1 | go-junit-report > result.xml", then the console doesn't print any more information HOT 4
- go-junit-report is failing with command not found...
- `-version` info is "not as useful" as it may should've been HOT 1
- have an option to exclude succeeded tests
- zsh: command not found: go-junit-report HOT 4
- [no test files] Not handled well by set-exit-code HOT 1
- New release HOT 2
- False error report in case of json parsing HOT 1
- Include arm64 builds in release assets HOT 1
- gotest output from 1.20+ is not properly parsed
- `flag provided but not defined: -in` HOT 1
- go-junit-report reports success after failing to compile code HOT 1
- benchmark tests marked as error when no unit test found HOT 1
- `system-out` is never placed under the correct `testcase` HOT 2
- Consider adding an option to prevent parsing lines starting with `#` as build output
- Better support of multiple test runs (`-count`)
- Linux arm64 binary missing HOT 3
- Capture test failures
- nested benchmarks are reported as failure
- How to enable coverage capture when used maxprocs
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from go-junit-report.