Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DRAFT | Implement Tests #32

Closed
wants to merge 2 commits into from
Closed

DRAFT | Implement Tests #32

wants to merge 2 commits into from

Conversation

monsieuremre
Copy link

This is a draft and not ready for merge. For now, running the application and opening a test AASX file is implemented as a test. This should be done manually by running the test.py, for now. Also the test should be terminated manually too. I have not pushed the test AASX file because I am not sure if it is ok to push with the current contents. It was a template from IDTA. Should I push this or should I create a custom examplary test AASX file for these tests?

Also I drafted a very primitive workflow. Did not test it yet, but will do soon, once the actual test that we want to run is more close to being complete. I drafted something to test the building process on linux, windows and macos. Did not test this either, and chances are it needs some fixes. The run test will also be done in all three os's, ideally. I will get into implementing this properly once the actual test is ready.

There are too many functions to test. What do we want to test actually? Testing everything is a really, really long task, and really not feasable to implement after the fact, especially since I am not familiar with the project code structure.

If we want to just test one or two select things, that would make more sense and it is also reasonable to implement.

I think it would be reasonable to implement a test like this:

  • build the program and run it, then open a file, then read the data, then add a submodule, then save the file, then close the application.

and this for all 3 operating systems. So if there is a very fundamental problem with a new merge, that breaks the build process or the opening of the application, we would be aware of this. Detailed problems won't be tested this way, like all the buttons and all the fiels in all windows etc. So small problems can still occur, but major ones will be detected, I guess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant