101–110 of 111 posts
Oh hey, we have the same sort of system here. It's 60,000 Python tests which take ~28 hours if run serially, but we keep it around 30-40 minutes. We wrote a UI & scheduler & artifact distribution system (which we're probably going to replace with S3). We run selenium & unit tests as well as the integration tests. We've noticed that starting and stopping a ton of docker containers in rapid succession really hoses dock…
hi frei
Earlier quoted context omitted.
Immutable data structures give you easy parallelism, however there's a hidden runtime cost: you have to allocate way more objects. For example, I was able to save a ton of object allocations here: https://github.com/mime-types/ruby-mime-types/pull/93 mostly by mutating. For tasks that are not easily parallelizable it may be slower to use immutable structures. I mostly only ever hear about how fast FP languages are, s…
Allocations don't have to be expensive if your GC is smart. Smart as C++ destructors positioning :D
Can you say more? I don't know how C++ uses destructor positioning? Seems to me if it gets to GC it's too late, you already made an allocation which is the expensive part.
Earlier quoted context omitted.
Immutable data structures give you easy parallelism, however there's a hidden runtime cost: you have to allocate way more objects. For example, I was able to save a ton of object allocations here: https://github.com/mime-types/ruby-mime-types/pull/93 mostly by mutating. For tasks that are not easily parallelizable it may be slower to use immutable structures. I mostly only ever hear about how fast FP languages are, s…
You can allocate stuff on the stack.
Earlier quoted context omitted.
Immutable data structures give you easy parallelism, however there's a hidden runtime cost: you have to allocate way more objects. For example, I was able to save a ton of object allocations here: https://github.com/mime-types/ruby-mime-types/pull/93 mostly by mutating. For tasks that are not easily parallelizable it may be slower to use immutable structures. I mostly only ever hear about how fast FP languages are, s…
Yes, mutating something at one place in memory is more efficient, because you don't need to allocate new memories. I don't know all to much about other functional languages, as I learned perl -> ruby -> javascript -> little bit C & Java & Go -> now doing Clojure. But I find Clojures collection data structures interesting. The vector (collection like lists or array) type look immutable, but under the hood are trees. W…
Earlier quoted context omitted.
That's basically what we did, but more like mocking things at the network communication boundary. But for an integration test, it was often unsatisfactory, because of things behaving differently than they do in the real world. We also had a suite of automated tests that communicated with real devices in a lab, which were much better, but extremely hard to maintain. My general experience was: tenable, but tricky. So I…
Was it not possible to build upon the mock device to make it run more realistically? I pretty much do this habitually now: 1. Get report of bug in production or on staging. 2. Write test to reproduce the bug. 3. 2/3 of the time get stuck because the environment isn't capable of mimicking the bug. 4. Build upon the integration testing environment to make it capable of mimicking the bug. I find the counter intuitive pa…
That's all I'm saying: tenable, but difficult (read: expensive). Frankly, I'm not convinced it is a worthwhile investment. Hence, my interest in how others have approached a similar problem.
Hitch looks pretty nifty, but I'm not sold on the yml/jinja2 approach. I grew to loathe Cucumber, and this approach seems similar. If you can't convince your non-technical staff to write tests in this language (which, in my experience, you can't), then you're better off writing the honest-to-god code that programmers are comfortable with (and can more easily modularize and refactor). YMMV I suppose!
Earlier quoted context omitted.
Was it not possible to build upon the mock device to make it run more realistically? I pretty much do this habitually now: 1. Get report of bug in production or on staging. 2. Write test to reproduce the bug. 3. 2/3 of the time get stuck because the environment isn't capable of mimicking the bug. 4. Build upon the integration testing environment to make it capable of mimicking the bug. I find the counter intuitive pa…
> I find the counter intuitive part of integration testing is that step 4 ends up being where most of the work is required and far too many people just don't do it because they feel it's not a worthwhile investment. That's all I'm saying: tenable, but difficult (read: expensive). Frankly, I'm not convinced it is a worthwhile investment. Hence, my interest in how others have approached a similar problem. Hitch looks p…
YAML is different. It has much clearer syntax and the method mapping is super easy and can even easily handle more complex data structures being passed in in the steps (lists, dicts, lists of dicts, etc.) which Cucumber either couldn't do, or required tortuous syntax and horrible regexps to do.
I did it this way mainly to adhere to the rule of least power and to enforce separation of concerns between execution code and test scenarios. Readability by non-programmers is just a nice side effect.
I suppose one day I might make a GUI to generate the YAML - maybe then non-technical staff might write tests, but probably not before.
Earlier quoted context omitted.
how do you trust the hosted CI company not to look at your code One can probably assume that they are not relying upon the secrecy of their code for security.
There are other reasons to keep code proprietary than fearing a security failure in the event the code leaks.
Earlier quoted context omitted.
Sure there are tons of languages, with different strengths and weaknesses. The part that is important is that the early engineers need to be productive in the language. Choose boring (to you) technology.
If the technology that's boring to "early engineers" has significantly more weaknesses than the alternatives, then, simply: the wrong people were hired.