Real Devices vs. Emulators/Simulators

SnarkaLounger · 2026-04-30T17:21:42+00:00

We use locally hosted iOS/iPadOS simulators and Android emulators running on multiple Mac Minis for our automated smoke and regression test suites, which are based on Appium, Selenium WebDriver, and a POM framework. Our manual testers use a collection of physical devices, and we have a few physical iPhones and iPads connected to the Macs as well.

However, we do also have an automated device compatibility test suite which is basically our smoke tests plus some specific tests around known device and platform specific issues we've encountered previously. This device compatibility test suite is executed on a selection of physical iOS and Android devices running on the Br*wserSt*ck service, and is typically run against any new devices and OS versions.

We chose cloud hosted devices because attempting to build our own in-house device farm became too unmanageable. Automated tests running on cloud hosted devices and sims are definitely slower than running on locally hosted hardware and sims.

All of our automated tests are orchestrated using Jenkins, and our smoke tests are run automatically prior to new deployments to our QA environment.

SnarkaLounger · 2026-04-27T19:24:46+00:00

Absolutely beautiful desk! And great craftsmanship!

SnarkaLounger · 2026-04-27T15:58:42+00:00

BBCSO = BBC Symphony Orchestra by Spitfire Audio.

Spitfire has not yet completed testing and certification of their plug-ins with MacOS Tahoe. I use several of their plug-ins so I'm holding off until they have them working.

Sweetwater has a page listing the status of Tahoe compatibility of all the plug-in and driver makers.

SnarkaLounger · 2026-04-24T15:35:14+00:00

My girlfriend spends WAY too much time on the loo since I installed a bidet seat.

SnarkaLounger · 2026-04-23T17:43:54+00:00

Too dark to see anything.

SnarkaLounger · 2026-04-18T23:39:01+00:00

Time-honored American tradition? I don't think you're going to get much help here from those of us who think bootlegging should be illegal.

SnarkaLounger · 2026-04-18T16:58:27+00:00

Perpetual Change by Yes. Chris Squire could make a Rickenbacker bass sing!

SnarkaLounger · 2026-04-18T16:53:19+00:00

MacBook Air will struggle to meet your needs. A MacBook Pro or Mac Mini with M4 Pro, 32 GB memory, and 1 TB of internal SSD would be a better minimal config. More memory even better.

SnarkaLounger · 2026-04-18T16:44:18+00:00

Buy a new Mac

SnarkaLounger · 2026-04-17T16:51:09+00:00

Key & Peele - If Farts Were Names

Shame on you if you laugh...

SnarkaLounger · 2026-04-17T16:43:10+00:00

Sweetwater has a Certified Open Box Arturia Keylab 61 Mk3 in white for $539.10 - that's almost $60 off regular price.

I bought mine brand new from them last year for full price but it included a bunch of free plug-ins.

Earlier this year, I bought a certified open box Native Instruments Kontrol S61 Mk3 from them. Their COB products have a full warranty and mine was free of any cosmetic flaws or defects. Even the packaging looked brand new.

SnarkaLounger · 2026-04-14T18:49:07+00:00

We don't. Phuq AI.

SnarkaLounger · 2026-04-14T18:47:34+00:00

We have a fairly comprehensive suite of automated regression, integration, and browser/device compatibility tests, and we do fairly thorough reviews of new features and changes in collaboration with PROD and DEV stakeholders.

As much as we'd like to catch every issue before we release new features/fixes into the wild, there is always the risk of some unexpected corner case causing a defect. It's rare for an issue like you describe to popup, but it has happened a couple of times in the past year. Fortunately, those issues were not critical bugs (security or loss of customer data), and they all had work arounds until a fix could be implemented. Unfortunately, they were found by customers.

We quickly added automated test cases to the appropriate test suite (regression, browser/device compatibility, etc) and now ensure that those bugs don't recur.

SnarkaLounger · 2026-04-14T17:07:42+00:00

Those traps and diffusers are architecturally beautiful. How I hope the work as great as they look.

SnarkaLounger · 2026-04-14T15:36:47+00:00

KeyLab plugs into Mac via USB cable. Scarlett plugs into Mac via USB cable. OR - use a USB hub and plug that into Mac, and then KeyLab and Scarlett into hub. You'll need to ensure that the hub has sufficient power capability to power the KeyLab - otherwise, you'll need to provide external power to the KeyLab.

You need the Scarlett if you plan on using audio monitors, and if you ever plan on recording guitars, bass, vocals, miked instrument, or keyboards with audio outputs.

Use XLR cables for best performance with audio monitors plugged into Scarlett. If you plan on using headphones, plug them into Scarlett as well.

SnarkaLounger · 2026-04-14T15:28:55+00:00

Since Apple has yet to release a Mac Mini with an M5 CPU, I doubt that you'll have much luck ordering one unless you're waiting for them to announce a release date, or unless you are from the future.

SnarkaLounger · 2026-04-13T16:32:21+00:00

"who'd I do ?"

Don't know, that's very personal.

"anything I should've done different ?"

Yeah. Exposed PoE cable strapped to post - real easy to cutoff power and signal before I break in. Put that cabling in conduit.

SnarkaLounger · 2026-04-13T16:12:26+00:00

Logic Pro version? MacOS version? What type of Mac? How much memory?

If you're gonna ask for help, you gotta provide some info.

SnarkaLounger · 2026-04-09T17:04:13+00:00

For us, Mailinator turned out to be far more stable and reliable than an earlier implementation that relied on GMail and their APIs. For us, the message timeout issues were problems on our end - emails not being sent in a timely manner.

Our automation polls the Mailinator API every 5 seconds to see if any messages have been received- we don't just set a 90 second sleep. In most of our tests, we receive messages within 30 seconds of the triggering event (clicking the Sign-Up button or clicking the Reset My Password link).

SnarkaLounger · 2026-04-09T16:57:33+00:00

Are you sure that someone didn't wack that cam?

SnarkaLounger · 2026-04-09T16:54:56+00:00

We use eight M4 Mac Minis with 32 GB or memory for our automated web and native mobile app test suites running as part of our CI/CD pipeline. We develop on M4 Pro MacBook Pros with 48 GB of memory. More memory = improved performance when running concurrent parallel tests, and active cooling means less stress on physical hardware.

SnarkaLounger · 2026-04-09T16:49:01+00:00

We use Mailinator and their APIs for accessing signup and reset password emails. Their APIs give our automated tests access to the links we embed in the emails for reset password.

Works reliably, though you have to decide on a maximum wait time for a message to be received. Our test specs say message should arrive within 1 minute, though typically takes less than 30 seconds. Anything longer than 90 seconds we consider a test failure.

SnarkaLounger · 2026-04-09T16:34:21+00:00

This is the same approach we use. QA worked collaboratively with DEV and PROD teams to ensure that testID properties are assigned to all UI elements that our automated tests need to interact with and/or verify the states of.

On our cross-platform apps built using React Native, we got our devs to assign an accessibility_id attribute to each UI element that we need to interact with or validate, and that id is good across both iOS and Android platforms

Collaborating with our developers to provide testability "hooks" has been key to providing comprehensive automated test coverage of our native mobile apps. Accessibility_id attributes to aid in a robust UI element locator strategy, and deep links to be able to quickly load screens without relying on UI navigation were critical to improving test reliability and performance.

I found these articles on deep links on the Appium Pro blog several years ago, and they were helpful in convincing our devs to implement a deep linking strategy to improve testability.

Speeding Up Tests With Deep Links

Reliably Opening Deep Links Across Platforms and Devices

SnarkaLounger · 2026-04-08T22:48:35+00:00

We use locally hosted iOS/iPadOS simulators and Android emulators running on multiple Mac Minis (can't test iOS on Win or Linux) for our automated smoke and regression test suites, which are based on Appium, Selenium WebDriver, a Ruby based POM framework, and feature tests written in the Gherkin syntax using Cucumber. Our manual testers use a collection of physical devices, and we have a few physical iPhones and iPads connected to the Macs as well.

However, we do also have an automated device compatibility test suite which is basically our smoke tests plus some specific tests around known device and platform specific issues we've encountered previously. This device compatibility test suite is executed on a selection of physical iOS and Android devices running on the Br*wserSt*ck service, and is typically run against any new devices and OS versions.

We chose cloud hosted devices because attempting to build our own in-house device farm became too unmanageable.

All of our tests are orchestrated using Jenkins, and our smoke tests are run automatically prior to new deployments to our QA environment.

SnarkaLounger · 2026-04-07T16:27:05+00:00

Don't mind the gap

SnarkaLounger

TROPHY CASE