Gusted be274b43a6 chore: add SQL fault injector testing (#9314) ... TL;DR we can test if transactions are actually working. Forgejo has many helper functions to test various aspects of the database state, however one aspect it is not able to test is transactions. As this would require that some random SQL query fails to indeed observe that the whole transaction is being rollbacked. So how do we make a random SQL query fail? Via a fault injector hook, which is always added to xorm (during unittest) and can be enabled on demand to say after how many SQL queries it should start returning a error (fault injecting). This allows a test to do the following: after two SQL queries lets call it a day and then execute the function that starts a transaction and does a few SQL query. It can then observe that indeed the function was fault injected (`ErrFaultInjected` is returned) and after querying the database it can observe that nothing was changed and thus can conclude the transaction was rollbacked. --- To demonstrate how the fault injector test helper can be used, lets add a test to a function I really wanted to test but couldn't because the fault injector didn't exist. `NewTwoFactor` was recently made into a transaction (a8c61532d2) and although it would not be catastrophic it would be really bad if records were being inserted if for some reason setting the secret failed. The test that's added demonstrates that the function uses a transaction and rollbacks correctly. Weirdly enough the fault injector can be viewed as testing a specification, because it assumes nothing about how the function does it (and you could even design a function that purposely doesn't work but succeeds this test), it merely assumes there's a transaction and within that transaction some SQL queries will be done. However it also needs a certain amount of knowledge about how the function is implemented because the developer needs to tell after how many SQL queries you want to inject a fault and you want to do at a point where there's already a observable change happening in the transaction and not fault inject if the transaction only contains `SELECT` queries. I'm sure you could design a smart fault injector that can do such guess work (although it sounds like a topic for a PhD thesis) and you could design a helper function that can then guide the fault injector to find every interesting place to do a fault injection and ensure the transaction always falls back; as a first prototype having the programmer tell after how many SQL queries a fault should be injected is sufficient for a lot of the transaction we are going to test in Forgejo. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9314 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Gusted <postmaster@gusted.xyz> Co-committed-by: Gusted <postmaster@gusted.xyz>		2025-09-18 00:39:06 +02:00
..
consistency.go	Update module github.com/golangci/golangci-lint/cmd/golangci-lint to v2 (forgejo) (#7367)	2025-03-28 22:22:21 +00:00
fault_injector.go	chore: add SQL fault injector testing (#9314)	2025-09-18 00:39:06 +02:00
fault_injector_test.go	chore: add SQL fault injector testing (#9314)	2025-09-18 00:39:06 +02:00
fixture_loader.go	chore: replace gopkg.in/yaml.v3 with go.yaml.in/yaml/v3 (#8956)	2025-08-20 15:31:12 +02:00
fixtures.go	chore: do not require empty fixtures to clean tables (#8353)	2025-06-30 23:04:16 +02:00
fscopy.go	chore: simplify CopyDir	2024-11-10 17:21:57 +01:00
mock_http.go	Fix migration failing when importing either issues or PRs but not the other (#8892)	2025-09-01 14:05:10 +02:00
reflection.go	Replace interface{} with any (#25686)	2023-07-04 18:36:08 +00:00
testdb.go	chore: add SQL fault injector testing (#9314)	2025-09-18 00:39:06 +02:00
unit_tests.go	chore: branding import path (#7337)	2025-03-27 19:40:14 +00:00