Hi, thanks for sharing this.

There is actually some relevance to this column, though in most scenarios this won't be obvious at all.

When distributing builds, NCrunch will run a build on every machine in the grid. Most of the results that are reported in the Tests Window for each project (i.e. the build time, when it was run, and the server) are obtained from the first build result returned by the grid for the project. The first result to return from the grid is considered 'primary' and has a special status in the engine, because it is used to obtain critical things like the list of tests in the assembly, IL hashes used for impact detection, etc. The rest of the results are mostly discarded with the exception of their build errors, as these can indicate an alignment issue between the nodes.

If you're running a reasonably fast machine compared with your grid nodes, most of the time the local node will respond first, which is why you always see (local). Probably this doesn't translate well to the tree structure, but then the tree itself is a massive oversimplification of the results you're seeing from the engine anyway so there will always be some rough edges on it.

I'm not really sure if there is a better way to handle the server reporting for build steps. Making it a delimited list can cause other problems for people using large grids. You can imagine what the column would look like if you had 30 machines in your grid. Leaving it blank or filled by a placeholder seems to deprive you of relevant information, as there would be no way to establish which server the other column values have come from. The 'Last Execution Time' value is still of some importance and this is only really relevant when you know which server was used to execute the build. It really doesn't seem like we have a perfect answer here.

Ouch, sorry :(



The key problem from an implementation (and actually UX) standpoint here is that the project row in the tree represents two different things:
1. The results specific to a project itself (i.e. its build and analysis steps)
2. Aggregated results from the tests and fixtures under this project

This problem also exists for the fixture rows. They represent both aggregated results from their child tests, as well as the results of the parent fixture, which has its own trace output and its own pass/fail result.

To take the standpoint that each row in the tree should be a clear aggregation of its child contents would be to lose critical information relevant to the row itself, which is more than just a grouping of child elements. For example, if we treated a project row as being merely a container of fixtures and tests, then there would be no where for us to report build results.

Of course it would be possible to build a separate UI structure that could show this data and leave the tree to aggregations, but then we'd have a whole new UI to manage and track. The nice thing about the Tests Window is that it gives you a full view of everything that would normally be relevant to someone in a standard NCrunch use case.

In my opinion, changing the Server row to be an aggregation would take it out of form with the rest of the data shown on the project rows, and this would make the view much more confusing. I accept that this might work better for your use case, but in the current design, all data shown for the project (with the exception of the icon/status) is derived directly from the primary build and analysis result with no aggregation performed. As soon as we start introducing selective behaviour for individual columns, all the consistency is gone.

For your use case, it may be better to group the Tests Window by Test instead, as the projects themselves probably aren't something you are interested in. In this manner, you can sort the individual test results by Server and it should give a very clear picture of pass/fail distribution by grid node. An alternative is also to export the results to CSV where you can easily sift through them in a spreadsheet.