jm + mocks   5

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
Testing without mocking in Scala
mocks are the sound of your code crying out, "please structure me differently!"

scala  via:jessitron  mocks  mock-objects  testing  testability  coding 
july 2015 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
TDD is dead. Long live testing
Oh god. I agree with DHH. shoot me now.
Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that's "slow". Like hitting the database. Or file IO. Or going through the browser to test the whole system. It's given birth to some truly horrendous monstrosities of architecture. A dense jungle of service objects, command patterns, and worse. I rarely unit test in the traditional sense of the word, where all dependencies are mocked out, and thousands of tests can close in seconds. It just hasn't been a useful way of dealing with the testing of Rails applications. I test active record models directly, letting them hit the database, and through the use of fixtures. Then layered on top is currently a set of controller tests, but I'd much rather replace those with even higher level system tests through Capybara or similar.

I think that's the direction we're heading. Less emphasis on unit tests, because we're no longer doing test-first as a design practice, and more emphasis on, yes, slow, system tests.
tdd  rails  testing  unit-tests  system-tests  integration-testing  ruby  dhh  mocks 
april 2014 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

Copy this bookmark: