I think to a certain extent we can create more unit tests that test out UI components. I have not done much of this but I believe that it is relatively common to do so for frontend heavy projects. However, in some cases in may be more involved some cases I have seen they write python selenium code to make sure that when you run the command the proper action is taken. For example, it would check to see that when you run the command to open the Infoset view that the infoset view is now actually opened. However, I am sure there are other ways of testing UI that I am just not familiar with. Moreover, I do think it would be best to have tests like this as if we don't we would need at least 2 people to pull down the code and fully test out the UI itself. If we have tests that just do it should make approving PRs easier and quicker.
On 2022/05/23 17:43:34 Mike Beckerle wrote: > Are there test automation tools available that can be used to drive the > vscode debugger? > > This would ideally include both something that drives the UI via easily > created/maintained scripts, but also things like code coverage analysis. > > I am always an advocate of built-in-self-test and of developers putting in > the test automation for new/changed features. > This is easy enough for libraries like the main daffodil library where we > also have codecov, and sonarqube analysis, and where the CI/CD pipeline > runs a test suite for us. > > The whole subject is harder for UIs where it depends on the ability to > script testing of the UI without the tests being so fragile that any change > to the UI breaks too many of them. > > When a PR is created for the Daffodil VSCode IDE, what is the developer's > expectation of what happens during code review? > E.g., Are you expecting that at least one reviewer downloads and builds the > new code base, and then tests the new/changed features? > Or are you expecting just code-scrutiny for advice on patterns/idioms, > likely errors, etc.? > > Please let's discuss. > > -mike beckerle >
