The way Arcade's builds send jobs to Helix was written using XUnit. XUnit lacks some of the flexibility that VSTests supports. In writing tests for SignCheck, I needed to update ARcade to spin up an entirely separate Helix queue just for the SignCheck tests. I also had to wire through utilizing the x86 console runner. I wrote the code to do this, but it's a lot of extra code, and not well vetted, yet.
#6800 (comment)
We could, either spend time reviewing those changes and testing this new feature of using the XUnit runner, or we could invest in #4539. My preference is the latter, but I'm not sure where that is on the priority list and if it's worth waiting on that before we add tests for SignCheck. On the flip side, we haven't had any SignCheck unit tests up to this point, so it's hard to build a case on that data point and I'm unsure what to do with the SignCheck PR in the interim..
The way Arcade's builds send jobs to Helix was written using XUnit. XUnit lacks some of the flexibility that VSTests supports. In writing tests for SignCheck, I needed to update ARcade to spin up an entirely separate Helix queue just for the SignCheck tests. I also had to wire through utilizing the x86 console runner. I wrote the code to do this, but it's a lot of extra code, and not well vetted, yet.
#6800 (comment)
We could, either spend time reviewing those changes and testing this new feature of using the XUnit runner, or we could invest in #4539. My preference is the latter, but I'm not sure where that is on the priority list and if it's worth waiting on that before we add tests for SignCheck. On the flip side, we haven't had any SignCheck unit tests up to this point, so it's hard to build a case on that data point and I'm unsure what to do with the SignCheck PR in the interim..