Emulator Issues #9148
open
Create testing plans/checklists for basic Dolphin features
0%
Description
2015-12-11 04:35:41 @delroth 2. starting to think about some test "checklists" that we can run through as a checklist to test most of the features in Dolphin when we start getting close to a release
2015-12-11 04:36:04 @delroth to avoid the 4.0 fiasco of "hey, single core crashes everywhere!"
2015-12-11 04:36:36 @delroth that way we'll have less chance of missing something I think, and it can be reused in the future.
2015-12-11 04:37:17 @delroth (I'm not sure how feasible it is, how much work it is, and how useful it will be. it just sounds like a good idea, it might not be, let me know if you think it isn't :) )
2015-12-11 04:37:45 @delroth JMC47: then just write down your testing procedures on a wiki page somewhere :P
Updated by JMC4789 over 8 years ago
The biggest thing is not to fall into the trap of using a checklist for each and every pull request. With the Real Wiimote testing, i mostly was worried about as many variables as possible.
MS Bluetooth Stack, Toshiba Stack, DolphinBar, regular wiimotes, -TR Wiimotes, Balance Board, etc.
I think that's the key to good testing; catching and testing as many situations as possible so we don't fuck it up by missing some scenario that's common.
Updated by MayImilae over 8 years ago
I'm a pretty thorough tester, I'd be glad to help make lists for testing things, and doing said lists!
Making a list is easy, making sure a super huge long thing doesn't have to be performed every time a PR is merged is more difficult...
Updated by delroth over 8 years ago
What might be useful is to have a list of test scenarios per impacted feature. We don't need to test CPU emulation stuff for a Bluetooth change. And for very small changes where the impact is well understood we probably won't need to run through all the test cases either.
However before main releases we probably want to run through all the checks we can think of.
Updated by JMC4789 almost 8 years ago
I've been working my ass off testing Dolphin in a variety of ways recently. I've tested every backend, input recording, and other things I never even knew how to use before.
I think for the final stage of testing we need to freeze everything, make a blog post and say "please test the latest dev version for regressions" and give it a week or two to see if anything pops up. For the first time, we can link to our issue tracker.
Updated by JMC4789 almost 8 years ago
Smashladder has been doing a wonderful job testing Netplay up to the release. Netplay is now 100% set assuming I don't break anything.
I've tested Wiimotes, Wiimote Plus, Wiimotion Plus -TR, Balance Boards, HID_USB support, Bounding Box, GBA <-> GCN, DSP-HLE, DSP-LLE, Interpreter, JIT, JITIL (to the degree it can be tested) OpenGL, D3D11, D3D12, Software Renderer and pretty much all the options within them. Tested Stereo3D again just to see if it worked. Played with AA, SSAA/MSAA, Fast/Slow-depth, tested depth sensitive games on an OGL 4.5 card to make sure clip-control was working.
I've also run through about 100 games the past few weeks, fully played through Tales of Symphonia on Netplay, managed to do a disc swap on netplay and it worked. Verified that Advance Game Port still works, GCI Folders, Memcards, Action Replay discs.
Dualcore is as crappy as ever, Single Core is slower but stable. I tested various cheat codes in a few games as well, along with the new Melee Cheats that Dansalvato posted.
I tested some Japanese language game, a few PAL games (including Another Code R: Journey into Lost Memories) and made sure various EFB2RAM things were working in the games with camera support. Verified that Wind Waker's Pictograph still gets pictures, Scrubbing Sirena Beach still works in Super Mario Sunshine in all backends.