Closed S-S-X closed 3 years ago
Finding out what causes single test case to fail with pull_request
action but succeed with push
action.
Tests are exactly same and all file contents are exactly same, pull_request
took ~15.5 seconds and push
took ~13.3 seconds.
So testing locally with cpulimit -l 2
which took 17 seconds to finish, 4 tests failed. All tests have something to do with results depending on time passed.
For example not enough ores smelted or grinded, network was executed only few times instead of what was expected.
Running again few times results vary based on how long it took to execute tests.
This most probably has something to do with max_lag.lua
and max lag throttling, lag values were faked before but now mod is loaded completely and lag values use actual real world time instead of faking it.
Not only that, same reason also causes per network lag to be significantly higher and cause network execution to skip cycles.
Have to fake both for consistent test results that wont be affected by real world limitations.
Answer: Implemented in https://github.com/mt-mods/mineunit/pull/27 Tested with cpulimit and limited a lot, over 2 minutes executing tests and all succeed:
69 successes / 0 failures / 0 errors / 1 pending : 128.714934 seconds
Performance update for Mineunit was good too:
73 successes / 0 failures / 0 errors / 1 pending : 17.358583 seconds
150 successes / 0 failures / 0 errors / 1 pending : 6.409515 seconds
77 new tests are 77 nodes registered during tests (ignoring not_in_creative_inventory nodes).
@OgelGames / @BuckarooBanzay to be able to add better tests for new API updates I would like to get this merged.
So here's the question:
This PR extends testing a lot but might be too fixed, it might be good thing as it enforces updating tests when there's big changes. But for exact same reason it might not be wanted
That's also reason why I'd like to have this while doing API upgrades for v2.0 release: guard new API against changes in interface and verify that updated API will actually follow specification. Especially I'd like to integrate this into #230, #232 and #233 as all those introduce API changes for upcoming release, from there it would be good to get immediate notification if changing anything might also affect API.
It seems like this should not cause any big troubles, been working fine over multiple changes and seems to be stable enough. I've tested this against all open pull requests and also for multiple stages in some branches.
Executed LoC goes from 631 to 5890, this count include only lines of code that actually do something.
For example end
, local varname
, else
and so on is excluded from counts mentioned.
Currently master branch has about 9219 lines of code counted like that (includes some of technic_worldgen and technic_cnc).
This PR extends testing a lot but might be too fixed, it might be good thing as it enforces updating tests when there's big changes. But for exact same reason it might not be wanted
IMO: More tests are better, updating the tests if there are big changes isn't really much more work (hopefully)
Lets merge it and see where it leads to...?
IMO: More tests are better, updating the tests if there are big changes isn't really much more work (hopefully)
Should not be, at least I've been writing temporary tests for things because it is way faster than starting Minetest world, logging in and clicking things. Fixing tests takes time but compatibility/behavior/API has changed when it has to be done.
If something goes wrong with Minetest and it crashes then you'll fix that thing and start over, if something goes wrong with Mineunit and it crashes then it happily proceeds to reset world and execute all of the remaining tests anyway.
At least for me tests allows faster big changes to underlying API while providing confidence without a lot of manual testing, actually since I've started Mineunit most of my play testing has been single last verification instead of finding and correcting typos or other stupid mistakes.
I'll review whole test set and clean up this updating for latest Mineunit where appropriate.
Cleaned up reducing duplicate initialization code and verified that set passes with master, machine API updates (after renaming solar arrays) and tool API updates. @OgelGames / @BuckarooBanzay want to still review this stuff?
Generic and targeted extended tests for Technic modpack
Not sure if this is good or wanted, Mineunit supports a lot of things but still not even nearly everything.
This PR extends testing a lot but might be too fixed, it might be good thing as it enforces updating tests when there's big changes. But for exact same reason it might not be wanted, dropping PR here anyway.
Current status
See comment https://github.com/mt-mods/technic/pull/208#issuecomment-946919098 for complete list of current tests as of 957c2b8.
Old report: Test coverage report for technic 9.62% in 10/103 files New report: Test coverage report for technic 64.48% in 117/117 files
Fixed annoyances
Also mineunit spamming a lot of warning
InvRef:get_list returning list src as reference, this can lead to unxpected results
, that's mineunit issue and not technic or regression test issue. I do remember adding that warning to mineunit InvRef implementation just because I was not sure if actual minetest engine returns those as references or if it uses deep copies / copy-on-write objects of direct references to original object.Test run on local machine, how many times these tests complain about possible "unxpected results" (yeah, just noticed typo too π€£):