-
Notifications
You must be signed in to change notification settings - Fork 226
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
Starting editor from command line is broken #2660
Comments
I already added a test (currently failing) in e87bbde |
@squiddy, thank you for letting me know. I will have a look at this asap. Not sure why the test would be failing, though. Maybe I should expand the "map-satisfying" conditions? EDIT: At least the error message is pretty clear :P. |
Not sure I understand. The test is failing because the functionality is broken. |
So it seems that when one tries to start a scenario from the command-line, the set of scenarios (object This requires an entirely different approach to the look-up algorithm. |
IMO we should write more tests for the command line interface, similar to e87bbde. Every usage of
Once we got those covered we should have more confidence in refactoring things. Maybe we don't want a single function that can do three things at once: load maps, load savegames, load scenarios. |
Without tests, the next change may break new things. We should strive to increase test coverage everytime we change things. |
The issue closed by itself, apologies. For now the code covers the following:
I tried to make it compatible with both the PS I agree on the tests, of course! EDIT: A good idea might also be to change the functions triggered by the individual command-line options to return EDIT2: development/stringpreviewwidget.py is broken as it escaped the 2to3 "purge" somehow. Will fix it soonish. |
Added more tests in 4860a2d Starting a scenario with a specific path seems to be broken. |
That is correct since the |
I added handling for the unittest that was failing: |
Once we have tests for the load-game functionality, I'd like to revisit the current implementation. I feel like it is more complex than before. We did however fix the scenario bug. Having one function for all these things isn't a good idea IMO |
I'm probably going to write these tests this evening. I don't like the workaround I have to do, but that's a minor issue compared with having no test at all. |
The current I think we also need a separate ticket to track our unittest coverage, right? @squiddy, could you open one, since you know best which tests still need to be implemented? :) |
We still need more tests, this whole refactoring basically broke all gui tests that relied on loading specific scenarios / maps that are not in the
|
Unfortunately, I had to implement some gimmicks for the path string, because the alternative was extracting the path from the I'll have a look at the code again and see how can I rebuild it or implement custom scenario/map paths. Also, I think it's a good idea to separate functions loading scenarios from those loading maps for the editor. |
@squiddy, I need to separate this code to be handled by two different functions: |
I split the EDIT: @squiddy, could you have a look whether the tests are running fine now? |
This particular issue is fixed. |
A quick check suggests that the fix for #2507 (PR #2651) broke this functionality. @AndyMender
The text was updated successfully, but these errors were encountered: