Age | Commit message (Collapse) | Author |
|
Panicking in ModuleForTests and similar test helper functions was
a mistake. Go's test runner stops running tests as soon as any
test panics, which means debugging multiple tests panicking requires
rerunning all the tests after fixing each panic to find the next
one. Pass the *testing.T into ModuleForTests and friends so that
it can call t.Fatalf instead.
Test: all soong tests pass
Change-Id: I5d0f2424eaf04fb795079e6d1e4b9469d8c7033c
|
|
Convert various mutators in tests to TransitionMutators.
Bug: 319288033
Flag: EXEMPT refactor
Test: all soong tests pass
Change-Id: I1da55889c391582a7c825c118c5988ec27820237
|
|
TestVariantSingletonModule tests that an error is produced when a
mutator creates variants of a SingletonModule. It also triggers
a data race when cloneLogicModules copies the properties, as the
ModuleFactory of a SingletonModule always returns the same module
with the same property structs. The build is about to fail with an
error anyways, so hopefully the data race isn't a problem. There
is no way to disable the test when the data race detector is enabled,
so disable it when -short is enabled, which is the case for all of
our CI testing.
Test: go test -race -short ./...
Change-Id: I944a4901acb60df8e590270f178961d95095a7e9
|
|
In preparation for test in the cc package.
Test: m nothing
Bug: 211770050
Change-Id: I3f6190e102c607a0b6246d78d7bde7fcffa21650
|
|
Bug: 183235980
Test: m nothing
Change-Id: I72898ada020ee1a73fd534c61afb5c22fa00c1e5
|
|
Bug: 182885307
Test: m nothing
Change-Id: I7f9f3eb66279fe5a2447aefa9b636144c32ce92a
|
|
A SingletonModule is halfway between a Singleton and a Module. It has
access to visiting other modules via its GenerateSingletonBuildActions
method, but must be defined in an Android.bp file and can also be
depended on like a module.
Bug: 176904285
Test: singleton_module_test.go
Change-Id: I1b2bfdfb3927c1eabf431c53213cb7c581e33ca4
|