I like running tests on a separate dedicated machine and enjoy a build environment that verifies each commit with a full test suite... but being able to run unit tests for a file on each save of a file is something that can save you some time pretty trivially.

I also disagree strongly about needing to run tests on the exact specs of your average consumer, most of us aren't writing software for a small set of hardware configurations so determining those average specs is likely not possible - but if you're working in an embedded platform or with specialized hardware I do agree that you absolutely do need to run tests on the actual hardware regularly, I'd still argue that those tests should be run on a dedicated machine and should be in addition to tests that verify the code is obeying its contract.

> should run at the exact specs of your average consumer.

Kinda expensive, having a set of multiple dedicated servers (or VMs) running on God knows how many dozen cores and hundreds of gb of ram just to run the tests that my laptop runs fine by itself, all in the name of running the "exact specs" that my stuff is going to be run on.

You're describing system testing, which takes place extremely late in the product cycle.

This argument is particularly badly formed. Tests are your application but you are testing for correctness not speed. In theory your tests could exercise as quickly as possible as many unique operations as a customer could perform in hours of normal use. You would never want this to take hours.

That pesky windows 10 won’t run on an msp430 unfortunately...