text:
Explain why service virtualization is a good idea in Readme

I would like to work on this with you.
Some input:
service virtualization helps in multiple ways:

helps us save the raw response that came from an external input/data source and decouples our tests from that external input/data source

We can then parameterize the test to first use hoverfly and then not to use it.
if the external input/data source slightly changes, our tests, when it does not use hoverfly now fails while the test that does use hoverfly continues to pass - making it clear our code has had no regression or bug introduced but the external input/data source has changed.
Now we can diff the cached response in hoverfly vs. the one that comes from the external input/data source the figure out what changed.
If we did not have this, we could go down a wild goose chase to figure out what happened (did the test fail because our code has had a regression or bug introduced or did the external input/data source change?)

@gc-ss hello! Thanks for the input. There's certainly value in this, but the same can be just as easily achieved with plain old mocks: run your tests against mocks, and then against real service. If the second run fails, you know it's due to the data source change.
In my experience, the value comes mostly from these things:

You don't spend time writing mocks
The data is 100% real, there's no chance that you messed up your mocks
It is a real network interaction. If you change your HTTP library, your tests will still work - or they will fail due to the differences in HTTP library, giving you valuable information. This also gives you the ability to test that you correctly work with your HTTP library (handle results and exceptions correctly)
You can play with the recorded data without calling the real service. E.g. you need to use a json field that you haven't used before - you can write the code and test it against the recorded data. If you wrote your mocks by hand, you would have probably included only the fields that you need, and then you have to update the mock

The biggest issues for me are:

People have to be taught
It's hard to rerecord simulations. E.g. you testing your k8s library. Then you need to create k8s objects by hand, record the simulations, then delete the objects. Sometimes setup can be quite complex compared to mocks
There is no way to check that all matchers in a simulation have been used

@gc-ss hello! Thanks for the input. There's certainly value in this, but the same can be just as easily achieved with plain old mocks: run your tests against mocks, and then against real service. If the second run fails, you know it's due to the data source change.
In my experience, the value comes mostly from these things:

You don't spend time writing mocks
The data is 100% real, there's no chance that you messed up your mocks
It is a real network interaction. If you change your HTTP library, your tests will still work - or they will fail due to the differences in HTTP library, giving you valuable information. This also gives you the ability to test that you correctly work with your HTTP library (handle results and exceptions correctly)

Exactly, the above reasons are very valuable and helps make the case WHY it's worth investing/spending time/effort on service virtualization.

You can play with the recorded data without calling the real service. E.g. you need to use a json field that you haven't used before - you can write the code and test it against the recorded data.

… and this not only saves time, effort but also exposes our code to real world data.

If you wrote your mocks by hand, you would have probably included only the fields that you need, and then you have to update the mock

Exactly. Another risk with the developer who wrote the code also writing the mock is that they often are biased with their thoughts and write the mock according to their own understanding.
Now as we know - bugs happen when understanding differs from reality.
Using service virtualization based off real world data, the understanding of the developer who wrote the code gets tested - not against some version of mock data that the developer thought should be, but what is.

The biggest issues for me are:

People have to be taught
It's hard to rerecord simulations. E.g. you testing your k8s library. Then you need to create k8s objects by hand, record the simulations, then delete the objects. Sometimes setup can be quite complex compared to mocks
There is no way to check that all matchers in a simulation have been used

I understand. Here are my thoughts on how you and I can help address these concerns:

People have to be taught

What if we make demos, python test samples and docs?

There is no way to check that all matchers in a simulation have been used

This could be hard but I have a few ideas with property based testing.

It's hard to rerecord simulations. E.g. you testing your k8s library. Then you need to create k8s objects by hand, record the simulations, then delete the objects. Sometimes setup can be quite complex compared to mocks

This is very true. This is the biggest challenge - and the answer is how much the business really values correctness and the money they are willing to spend to ensure correctness. The best you and I can do is make recommendations, so we make demos, python test samples and docs to highlight what service virtualization brings to the table.

w.r.t. rerecording, I think the best approach is to use pytest fixtures to create/destroy resources. But currently the network requests from fixtures will be intercepted by Hoverfly. And there should be a way to tell the resource fixtures that they are in a simulation and don't need to do anything. But this is a separate issue.. Also, maybe @hoverfly decorator should accept some optional setup_instructions parameter, to encourage people to write down the things that have to be done to re-record. I found it to be a huge problem, when people other than the original author have to rerecord tests.

What if we make demos, python test samples and docs?

I found that the most annoying part is debugging the tests. Currently, if an http request fails to match, the plugin spits out Hoverfly's error logs. These are hard to parse for a person that does not have experience with Hoverfly. This can be fixed by parsing the error logs and outputting the more informative diff, but I haven't got time to do this yet.
Anyway, if you'd like to work on this, PRs are welcome :)

w.r.t. rerecording, I think the best approach is to use pytest fixtures to create/destroy resources.

Agreed.

But currently the network requests from fixtures will be intercepted by Hoverfly. And there should be a way to tell the resource fixtures that they are in a simulation and don't need to do anything. But this is a separate issue..

This makes sense only if you're monkeypatching the proxies for the underlying libraries. I need to read the your code but if you are doing that - don't. It might feel like making it easy for the user but then the user will have to fight/undo the monkeypatching if they have a well designed software where they are passing proxies to their underlying library correctly - eg, for requests: (https://docs.python-requests.org/en/latest/api/#requests.request)
Let the person writing the test do that if needed. We can show them how to monkeypatch using fixtures themselves if needed.
For example, if requests is being used, we can easily pass the proxy host and port information as I am pointing out to another testing framework author here: https://github.com/taverntesting/tavern/issues/673#issuecomment-822082204
What do you think?

I found it to be a huge problem, when people other than the original author have to rerecord tests.

Can you explain a bit why it's a huge problem?
From my POV, rerecording tests should be as simple as deleting the existing saved simulation, turning recording on, saving the new simulation, turning recording off.
This is because the test environment is already setup with the exact, correct environment including credentials/tokens/resource paths etc to make the request.
What am I missing?

I found that the most annoying part is debugging the tests. Currently, if an http request fails to match, the plugin spits out Hoverfly's error logs. These are hard to parse for a person that does not have experience with Hoverfly. This can be fixed by parsing the error logs and outputting the more informative diff, but I haven't got time to do this yet.

I would need to have a look at some of the real world tests you're writing to understand the context.
They way I use Hoverfly is to act as a cache and then turn off networking in the container that runs the test.
As a result, those requests that are cached by Hoverfly return the cached response but if my tests make an unexpected query that is, as a result, not already cached by Hoverfly, it finds not match and sends the request through and the request fails as it cannot find the actual server.
If you show me your test I can explain better. Otherwise I can write a sample test with the dockerfiles if you would like to check them out but this will take a week or so to get to you.

Anyway, if you'd like to work on this, PRs are welcome :)

Sure! I do need to understand from you what your criteria/requirements to merge in PRs are but we can talk over email for that.

@gc-ss You are right, there should be a way to turn off patching of the env vars. I think we still should patch by default though, as it lowers the entry barrier.

Can you explain a bit why it's a huge problem?

Exactly because there may be no info on how to prepare the required resources. It is not always possible or optimal to automate such creation. So in a lot of cases, there is a need for a textual instruction, thus my idea about setup_instructions param.

I would need to have a look at some of the real world tests you're writing to understand the context.
Yes, the request fails if no match is found. But it is not immediately obvious why it fails.

This plugin detects that the test has failed, and prints the error logs from Hoverfly if there are any. But these logs can be made more informative.

authors: WouldYouKindly gc-ss

repo: wrike/pytest-hoverfly


text:
Update tr_tr.lua

See #49

source: gharchive/pull-request

repo: wrxck/mattata

license: mit

license_type: permissive

license_source: bigquery


text:
Update .gitignore

Uhm. This is a little much for this project i'm afraid. We can probably add some additional items to our gitignore, but we really don't need any django or celery (to name a few). Why add so much?

@Kilian in case you need it in the future :)

Agree with @Kilian, this seems excessive.

repo: xflux-gui/xflux-gui


text:
Fix associativity in build.sh desync check

Coverage remained the same at 82.641% when pulling 18883e9b03cbd46c9705c74057b90bcd4db0c6fe on xiphmont:silly into 06c8bda12f96a2602b490dd25477c8514f79cf07 on xiph:master.

authors: coveralls xiphmont


text:
mention render/renderString changes in the CHANGELOG

Thanks I updated the text, and pushed to pub.
Breaking change: Template.render and Template.renderString methods no longer take the optional lenient and htmlEscapeValues. These should now be passed to the Template constructor.

Thumbs up!

authors: xxgreg yjbanov

repo: xxgreg/mustache


text:
Fix makefile to correctly pass the prefix to perl install

👍

+1

authors: areese bluelamar nelson-maltez

repo: yahoo/mdbm


text:
Investigate feasibility of add service distributed tracing by sleuth and zipkin

The latest version of spring seem not support embed a zipkin server inside spring boot application. Lots of effort for this. Exclude this from demo

source: gharchive/issue

repo: yaweiw/azure-spring-cloud-playground

license_source: github-api


text:
feat: migrate crvUSDN and crvUSDP to v2

Found address 0x881b06da56BB5675c54E4Ed311c21E54C5025298 in files app/containers/Vaults/customOrder.json. This address is from vault yLINK
Found address 0x1B5eb1173D2Bf770e50F10410C9a96F7a8eB6e75 in files app/containers/Vaults/customOrder.json, app/containers/Vaults/migrationWhitelist.json. This address is from vault yvusdp3CRV
Found address 0xFe39Ce91437C76178665D64d7a2694B0f6f17fE3 in files app/containers/Vaults/customOrder.json, app/containers/Vaults/migrationWhitelist.json. This address is from vault yvusdn3CRV
Found address 0x7047F90229a057C13BF847C0744D646CFb6c9E1A in files app/containers/Vaults/customOrder.json. This address is from vault yvCurve-renBTC
Found address 0xC4dAf3b5e2A9e93861c3FBDd25f1e943B8D87417 in files app/containers/Vaults/customOrder.json, app/containers/Vaults/migrationWhitelist.json. This address is from vault yvCurve-USDP
Found address 0x3B96d491f067912D18563d56858Ba7d6EC67a6fa in files app/containers/Vaults/customOrder.json, app/containers/Vaults/migrationWhitelist.json. This address is from vault yvCurve-USDN
Found address 0x7Eb40E450b9655f4B3cC4259BCC731c63ff55ae6 in files app/containers/Vaults/migrationWhitelist.json. This address is from token usdp3CRV
Found address 0x4f3E8F405CF5aFC05D68142F3783bDfE13811522 in files app/containers/Vaults/migrationWhitelist.json. This address is from token usdn3CRV

I updated the custom order to remove duplicates from v1, and complete revamped ordering of the stablecoin vaults in v2

authors: dudesahn patcito

repo: yearn/yearn-finance

license: MIT


text:
Upgrade peer-dependency to Angular ^7.0.0

:tada: This issue has been resolved in version 5.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

authors: visurel yisraelx

repo: yisraelx/ngx-showdown


text:
Do you have w48 or w32 tf pretrained models?

no. I did not train w32 and w48 models. I don't think i will train them recently due to GPU shortage.

no. I did not train w32 and w48 models. I don't think i will train them recently due to GPU shortage.

Thank you for your answer


text:
improve soncumer-kafka-quarkus coverage

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 1

Coverage increased per file
===========================
+ application/jaxrs-activemq-quarkus/src/main/java/webapp/tier/service/ActiveMqService.java  4

Coverage decreased per file
===========================
- application/redis-mysql-helidon/src/main/java/webapp/tier/util/GetConfig.java  -50

Complexity increasing per file
==============================
- application/consumer-kafka-quarkus/src/test/java/webapp/tier/service/MockDeliverService.java  1
- application/consumer-rabbitmq-quarkus/src/test/java/webapp/tier/healthcheck/ReadinessHealthCheckRabbitmqSubscriberTest.java  1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 1

Complexity increasing per file
==============================
- application/consumer-rabbitmq-quarkus/src/test/java/webapp/tier/healthcheck/ReadinessHealthCheckRabbitmqSubscriberTest.java  1
- application/consumer-kafka-quarkus/src/test/java/webapp/tier/service/MockDeliverService.java  1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- application/consumer-rabbitmq-quarkus/src/test/java/webapp/tier/healthcheck/ReadinessHealthCheckRabbitmqSubscriberTest.java  1
- application/consumer-kafka-quarkus/src/test/java/webapp/tier/service/MockDeliverService.java  1

See the complete overview on Codacy


text:
Fix dependencies for zf3

The .travis.yml file will also need to be updated to match, as it's currently hard-coded to PHP 5.3/5.4

Fixed with #11

authors: adamlundrigan akrabat joepsyko


text:
Add persian language

Thanks for this @aliruss. @niusha-paks will do a review ASAP!

hi @kefranabg and you'r welcome

Hi @aliruss, are you ok to consider @niusha-paks review ? 😃

@all-contributors please add @niusha-paks for review

authors: aliruss kefranabg


text:
guide 中的图片 挺多已经无法展示，是否可以补充一下

网络问题，有时候被墙了，翻墙即可

authors: IlovePea zhuifengshen


text:
Allow takeoffs to be aborted.

oh! could the "v status" replace knots on tag on takeoff? then we could see if it's too late to abort! once a craft hits, say..1000 ft then the knots would replace v staus.

Takeoffs can be aborted, yet I do like the V status. Opened a new issue (#268) for this and I think this one can be closed now, @zlsa

authors: Maverick283 sixeyeco zlsa

repo: zlsa/atc


text:
adds blog footer

@IamManchanda Can you please look over for merge?

repo: zurb/building-blocks


text:
added function upload_secrets_dict

Toevoeging "upload_secrets_dict" als functie. Hiermee kunnen we simpelweg een dictionary van secretnames en secret values uploaden naar keyvault

repo: zypp-io/keyvault


text:
New PR to test SignCLA at 2019-07-18 17:29:42.062249264 -0700 PDT m=+4.486025361

Body of PR

indiv-pass-staging: test succeeded

repo: google-test/signcla-probe-repo-dev