Any practical suggestions on how to bootstrap testing (unit and/or UI) for an existing project that has never seen any? Or any recommended resources I could read up on?
Particular resources and guides are gonna depend heavily on language/frameworks/etc.
Start with areas that are the most valuable to the business. Not only does this more easily show the (business) value of testing, but it helps keep you from introducing a very visible and very bad looking regression. Anything dealing with money (especially billing) is probably a good indicator. Be warned, here be dragons.
That being said, don't verify your testing setup with business critical tests. Verify your setup (to yourself and other devs) with the quickest thing you can accomplish. The business critical ones are your (team's) short term goal.
Pick out the X most important logic paths (e.g. customer checkout or some subsection of that). Work on regression testing that over the next few months.
Make sure your tests are both automated and actually get run. The latter is more important than the former.
Ideally, your tests will prevent a nasty bug from going in and will immediately prove the business value of your testing efforts. This will establish the trust you need to continue testing and refactoring.
Hmm.. it's definitely tough to begin on a codebase with 0% coverage.
The first step is to stop the bleeding so begin adding unit tests for any new code you write and be sure to factor this effort in with your sprint estimations.
In parallel work top down with high level integration tests written against feature flows. E.g., As a user when I select this then I expect this. This doesn't mean you need to actually use BDD gherkin library for your test runner but at least frame the context of these in that regard since you don't care about the minute details of the underlying code, just the experience of the user story.
And lastly, don't just write tests to write tests, try to understand what is important to cover against because there is nothing worse than maintaining barely useful tests wired up to legacy data fixtures.
> The idea is to use something that gives a fake readout of your fingerprint thus making you look normal but keep changing it occasionally so it leads no where for long time.
What is "normal" in this case? One correct way to counter fingerprinting is to standardize the fake readouts to a specific value and not change it every so often. So if everyone's browser is reporting the same value for this feature that feature will become meaningless in the context of fingerprinting since its entropy is very low.
That's what Tor Browser has been doing with font enumeration, reported windows size, screen resolution etc. - they all report the same value. On the other hand, you can correlate these values and identify Tor Browser users.
