search

walmartlabs / krabby

4 stars 5 forks source link

should git knowledge be built into the tests? #23

Closed patrickkettner closed 9 years ago

patrickkettner commented 9 years ago

the tests are super dumb right now. A number of interesting tasks could involve git, its metadata, and so on.

Should we build git knowledge into the test (so it has access on _baseTest.prototype)? Or perhaps this would just mean supporting sub constructors (something like _baseTestWithGit) that decorates _baseTest with more properties?

cc @baer

baer commented 9 years ago

Sorry when you say tests you mean the testers right?

baer commented 9 years ago

Do you have a bunch of testers in mind that could use git or are you proposing we write a bunch of different base testers to make it really easy for somebody else to write one? I definitely see the benefit but I don't know if it makes sense in a base test.

patrickkettner commented 9 years ago

What I meant was something on baseTest that would detect if the project was run inside of a git repo, and if so, add a .git object to the prototype, with stuff like current branch, current commit, etc. That way tests would have easy access to that data without having to roll it itself

On Thu, Apr 23, 2015, 2:10 PM Eric Baer notifications@github.com wrote:

Do you have a bunch of testers in mind that could use git or are you proposing we write a bunch of different base testers to make it really easy for somebody else to write one? I definitely see the benefit but I don't know if it makes sense in a base test.

— Reply to this email directly or view it on GitHub https://github.com/patrickkettner/krabby/issues/23#issuecomment-95674159 .

baer commented 9 years ago

I understand what it would do I just wonder if it will be used enough to justify pulling it into the baseTest. I could maybe see a reason to roll this into a baseReport so we can generate output that specifies the branch name but I can't think of any tests off the top of my head that would need this. Lets keep writing reporters and see if this becomes something we can do to keep the code DRY. Right now it seems premature unless you had something specific in mind.

patrickkettner commented 9 years ago

I have a number of tests in mind, a showed off some at the standup yesterday

average github issue age file churn - dig through the repo to determine how frequently files are changed long running branches - if a non master/prod/(something marked in the config) is maintained for an extended period of time, do something with that information (ensure that branch is tested, etc)

@ryan-roemer wanted a submodule drift one, as well

you are totally right though. We need to figure out if there are any trends with tests/reports before building in more support. the level head is greatly appreciated

patrickkettner commented 9 years ago

closing until this becomes needed