jm + mocking   8

atlassian/localstack: A fully functional local AWS cloud stack. Develop and test your cloud apps offline!
LocalStack provides an easy-to-use test/mocking framework for developing Cloud applications. Currently, the focus is primarily on supporting the AWS cloud stack.

LocalStack spins up the following core Cloud APIs on your local machine:

API Gateway at http://localhost:4567;
Kinesis at http://localhost:4568;
DynamoDB at http://localhost:4569;
DynamoDB Streams at http://localhost:4570;
Elasticsearch at http://localhost:4571;
S3 at http://localhost:4572;
Firehose at http://localhost:4573;
Lambda at http://localhost:4574;
SNS at http://localhost:4575;
SQS at http://localhost:4576

Additionally, LocalStack provides a powerful set of tools to interact with the cloud services, including a fully featured KCL Kinesis client with Python binding, simple setup/teardown integration for nosetests, as well as an Environment abstraction that allows to easily switch between local and remote Cloud execution.
aws  emulation  mocking  services  testing  dynamodb  s3 
5 weeks ago by jm
Fake Time
'FakeTime is simulated time."
When testing RealTime software a simulator is often employed, which injects events into the program which do not occur in RealTime.
If you are writing software that controls or monitors some process that exists in the real world, it takes a long time to test it. But if you simulate it, there is no reason in the simulated software (if it is disconnected from the real world completely) not to make the apparent system time inside your software appear to move at a much faster rate. For example, I have written simulators that can verify the operational steps taken by industrial controllers over a 12 hour FakeTime period, which executes in 60 seconds. This allows me to run '12 hours' of fake time through my test cases and test scenarios, without waiting 12 hours for the testing to complete. Of course, after a successful fakeTime test, an industrial RealTime system still needs to be tested in non-simulated fashion.
faketime  time  testing  mocks  mocking  system-tests 
august 2016 by jm
Mock Boto: 'a library that allows your python tests to easily mock out the boto library.' Supports S3, Autoscaling, EC2, DynamoDB, ELB, Route53, SES, SQS, and STS currently, and even supports a standalone server mode, to act as a mock service for non-Python clients. Excellent!

(via Conor McDermottroe)
python  aws  testing  mocks  mocking  system-tests  unit-tests  coding  ec2  s3 
may 2014 by jm
Resiliency And Elasticsearch
Blog post from the ES team. They use "evil tests" -- basically unit/system tests, particularly using randomized error-injecting mock infrastructure. Good practices; I've done the same myself quite recently for Swrve's realtime infrastructure
elasticsearch  resiliency  network-partitions  reliability  testing  mocking  error-injection 
april 2014 by jm
'A Ruby gem providing "time travel" and "time freezing" capabilities, making it dead simple to test time-dependent code. It provides a unified method to mock,, and in a single call.'

This is about the nicest mock-time library I've found so far. (via Ben)
time  ruby  testing  coding  unit-tests  mocking  timecop  via:ben 
october 2013 by jm
Don’t Overuse Mocks
hooray, sanity from the Google Testing blog. this has been a major cause of pain in the past, dealing with tricky rewrites of mock-heavy unit test code
mocking  testing  tests  google  mocks  unit-testing 
may 2013 by jm
Test Double is a generic term for any case where you replace a production object for testing purposes. There are various kinds of double that Gerard lists:

Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an InMemoryTestDatabase is a good example).
Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test.
Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
Mocks are pre-programmed with expectations which form a specification of the calls they are expected to receive. They can throw an exception if they receive a call they don't expect and are checked during verification to ensure they got all the calls they were expecting.
test-doubles  naming  patterns  tdd  testing  mocking  tests  martin-fowler 
april 2013 by jm
'a HTTP client mock library for Python, 100% inspired on ruby's FakeWeb [ ].' 'HTTPretty monkey patches Python's socket core module, reimplementing the HTTP protocol by mocking requests and responses.'
mocking  testing  http  python  ruby  unit-tests  tests  monkey-patching 
january 2013 by jm

Copy this bookmark: