From 5a77179c74340b683c75cbb271edc58e96052bcf Mon Sep 17 00:00:00 2001 From: oatkiller Date: Mon, 10 Aug 2020 12:48:22 -0400 Subject: [PATCH] remove readme. --- .../public/resolver/mocks/README.md | 22 ------------------- 1 file changed, 22 deletions(-) delete mode 100644 x-pack/plugins/security_solution/public/resolver/mocks/README.md diff --git a/x-pack/plugins/security_solution/public/resolver/mocks/README.md b/x-pack/plugins/security_solution/public/resolver/mocks/README.md deleted file mode 100644 index af9e7639391fd..0000000000000 --- a/x-pack/plugins/security_solution/public/resolver/mocks/README.md +++ /dev/null @@ -1,22 +0,0 @@ -* reuse in mocks is good - - because if all mocks need to change, you change them easier and have all the tests run against the new version? - - if theres a bug in the way we make a mock, we want to fix it everywhere - - the mock mocks something we have in production, so if the iterface or design that changes, all mocks need to change -* mocks should have deterministic, concrete, unique, interesting behavior: - - a resolver tree with no ancestors - - 2 children - - the origin has 2 related events - - 'when analyzing a tree with 2 children' - - 'when analyzing a tree with no ancestors' - -* internally to the 'mocks' module - - feel free to use helpers, composition, configuration, parameters, etc - -* mocks exported should have little or no configuration, a very specific name, - -* mock metadata - - when a mock uses interesting data like entity_ids, process names, times, PIDs, etc, that a test will check, then export that stuff in an object from the module that defines the mock - - that way it can be used in the `describe` and `it` blocks that give the test a name - -* prefer to mock DataAccessLayer and ResolverTree - - also mock the payloads of any action