Karate: Test Automation Made Simple
github.com
Karate: Test Automation Made Simple
1–10 of 20 posts
Re: Karate: Test Automation Made Simple
#2“Made simple”. Well...I tried it and it’s by far the most complex, sprawling, cluttered, “everything under the sun” testing framework I’ve ever encountered.
I kinda liked the premise, but take “simple” with a truck load of salt.
Re: Karate: Test Automation Made Simple
#3Having done some chidokai, first thought on seeing the site is "wow, that's a poor stance". YMMV
Re: Karate: Test Automation Made Simple
#4“Made simple”. Well...I tried it and it’s by far the most complex, sprawling, cluttered, “everything under the sun” testing framework I’ve ever encountered. I kinda liked the premise, but take “simple” with a truck load of salt.
> Wow that is a long README.md file
My first thought when I entered the page ;-)
Re: Karate: Test Automation Made Simple
#5Readme should probably have word "Java" somewhere in the first line.
Re: Karate: Test Automation Made Simple
#6Doesn't seem to support property-based testing, which is my default go-to for automated testing, so I'll give it a miss.
(I've had good experiences with QuickCheck for Haskell, Hypothesis for Python, ScalaCheck for Scala, JSVerify for Javascript)
Re: Karate: Test Automation Made Simple
#7I can't help but note that Intuit, who profits off of complexifying the "simple" tax code, cannot see the complexity in their "simple" test automation framework. Conway's Law strikes again.
Re: Karate: Test Automation Made Simple
#8given that some test people might be reading these comments - is anyone aware of a configuration for test frameworks that:
1. lets users opt code out of the testing footprint (I know this is a given), but also
2. monitors opted-out code for being called a certain number of times, therefore meaning it's depended upon, therefore meaning it SHOULD be tested, and gets flagged?
I feel like this would be the way to go to minimize non-valuable testing while allowing you to discover code thats becoming more leveraged and therefore more critical to test.
Re: Karate: Test Automation Made Simple
#9given that some test people might be reading these comments - is anyone aware of a configuration for test frameworks that: 1. lets users opt code out of the testing footprint (I know this is a given), but also 2. monitors opted-out code for being called a certain number of times, therefore meaning it's depended upon, therefore meaning it SHOULD be tested, and gets flagged? I feel like this would be the way to go to m…
1. In any testing framework I've used, this is (as you said) a given. The exact mechanism you have for slicing and dicing your tests varies, but this is usually well supported IMO.
2. This feels like the job of a code coverage tool to me (and it's something I would like as well), but most coverage tools I've seen don't quite have the granularity you're looking for. In certain ecosystems you could hack something together pretty quickly (e.g. the `trace` module in python).
Correct me if I'm wrong, but this idea sounds like you'd like to bias your tests away from small units and toward integration tests (and a similar tool could be useful for dead code elimination and a few other tasks). I know they're not a panacea in general, but in your personal experience what problems have you found in fine-grained tests that outweigh their benefits?
Re: Karate: Test Automation Made Simple
#10given that some test people might be reading these comments - is anyone aware of a configuration for test frameworks that: 1. lets users opt code out of the testing footprint (I know this is a given), but also 2. monitors opted-out code for being called a certain number of times, therefore meaning it's depended upon, therefore meaning it SHOULD be tested, and gets flagged? I feel like this would be the way to go to m…
1. In any testing framework I've used, this is (as you said) a given. The exact mechanism you have for slicing and dicing your tests varies, but this is usually well supported IMO. 2. This feels like the job of a code coverage tool to me (and it's something I would like as well), but most coverage tools I've seen don't quite have the granularity you're looking for. In certain ecosystems you could hack something toget…
I could see something like this being extremely useful when working with legacy code. In the book "Continuous Delivery (Humble, Farley)" they suggest when working in legacy code without tests, to begin adding testing to systems starting only with the parts you changed. If this is hard to determine, a test feature that shows unit dependencies could be really helpful.