I want to talk about a web application for executing test runs and viewing results. Lets say that the tests are authored in VS and that they are categorized by means of attributes. The user is able to select one or more categories of this test for execution. For each run, the corresponding mstest arguments are set and invoked. The web page itself has a progress indicator for the duration of the test execution. The test run is invoked by a command line an d is independent of the portal view. The results of the test run could be displayed with the availability if a trx file from the run or from a database where the results are populated independently. The tests themselves have names, owners, categories and the path to the assembly so they can be found and executed. The test execution and history can also be displayed from files or database. What we need us the minimal logic to kick off a run and show the results. The results for each run could then show the history of each test. Since the views are only about the test results and the input to kickoff a run, the models are for the runs/results and the test/category to be executed.
The views are separated out into the list view and the details view for each results. The list view could have additional features such as paging, sorting, searching etc. to make it easier to navigate the test results but the details page only requires the path to the trx file and a drill-down into the history of individual tests within the category. The web page could be personalized to display the signed on user and the test runs associated with that user. This requires the use of AD integration for the login if the webpages are to be displayed internally. A domain name registration could help reach this web application by name.
The reason for describing this web application is to see if the implementation can be done with minimal code and leveraging the latest MVC webAPI frameworks to get great working results. This will allow the views and pages to be added rapidly. So far we have talked about the controller kicking off the run and returning a default view. Then the views get updated when the results are ready. Since the completion is dependent on when we have a trx file or the results in the database, the two are handled separately.
In other words, we display the web page caters to the convenience of kicking off the run and waiting for the results. To talk about the process where the results are populated into a database offline, we could use either a custom executable or the option with mstest to publish the results to TFS. The latter is convenient in the sense that TFS already enables web access and navigation so our portal doesn't need to do a lot.
Finally, we display the results with JQuery progress bars, itemized row level styles and overall page beautifying style and content layout. The web pages could also have themes and variations based on how the tests are populated. For example, for tests that target say MSMQ, the tests could optionally show which queues are targeted.
The views are separated out into the list view and the details view for each results. The list view could have additional features such as paging, sorting, searching etc. to make it easier to navigate the test results but the details page only requires the path to the trx file and a drill-down into the history of individual tests within the category. The web page could be personalized to display the signed on user and the test runs associated with that user. This requires the use of AD integration for the login if the webpages are to be displayed internally. A domain name registration could help reach this web application by name.
The reason for describing this web application is to see if the implementation can be done with minimal code and leveraging the latest MVC webAPI frameworks to get great working results. This will allow the views and pages to be added rapidly. So far we have talked about the controller kicking off the run and returning a default view. Then the views get updated when the results are ready. Since the completion is dependent on when we have a trx file or the results in the database, the two are handled separately.
In other words, we display the web page caters to the convenience of kicking off the run and waiting for the results. To talk about the process where the results are populated into a database offline, we could use either a custom executable or the option with mstest to publish the results to TFS. The latter is convenient in the sense that TFS already enables web access and navigation so our portal doesn't need to do a lot.
Finally, we display the results with JQuery progress bars, itemized row level styles and overall page beautifying style and content layout. The web pages could also have themes and variations based on how the tests are populated. For example, for tests that target say MSMQ, the tests could optionally show which queues are targeted.
No comments:
Post a Comment