jm + integration-testing   6

Why did Apple, Amazon, Google stocks crash to the same price today?
Nasdaq said in a statement that "certain third parties improperly propagated test data that was distributed as part of the normal evening test procedures."

"For July 3, 2017, all production data was completed by 5:16 PM as expected per the early close of the markets," the statement continued. "Any data messages received post 5:16 PM should be deemed as test data and purged from direct data recipient's databases. UTP (Unlisted Trading Privileges) is asking all third parties to revert to Nasdaq Official Closing Prices effective at 5:16 PM."
testing  fail  stock-markets  nasdaq  test-data  test  production  integration-testing  test-in-prod 
16 days ago by jm
Awesome new mock DynamoDB implementation:
An implementation of Amazon's DynamoDB, focussed on correctness and performance, and built on LevelDB (well, @rvagg's awesome LevelUP to be precise). This project aims to match the live DynamoDB instances as closely as possible (and is tested against them in various regions), including all limits and error messages.

Why not Amazon's DynamoDB Local? Because it's too buggy! And it differs too much from the live instances in a number of key areas.

We use DynamoDBLocal in our tests -- the availability of that tool is one of the key reasons we have adopted Dynamo so heavily, since we can safely test our code properly with it. This looks even better.
dynamodb  testing  unit-tests  integration-testing  tests  ops  dynalite  aws  leveldb 
november 2015 by jm
Smart Integration Testing with Dropwizard, Flyway and Retrofit
Retrofit in particular looks neat. Mind you having worked with in-memory SQL databases before for integration testing, I'd never do that again -- too many interop glitches compared to "real world" MySQL/Postgres
testing  integration-testing  retrofit  flyway  dropwizard  logentries 
june 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
DynamoDB Local
'a client-side database that supports the complete DynamoDB API, but doesn't manipulate any tables or data in DynamoDB itself. You can write code while sitting in a tree, on the beach, or in the desert. When you are ready to deploy your application, you simply instruct it to connect to the actual DynamoDB endpoint. No other modifications will be needed.'

This is good -- an in-memory data store for integration testing is absolutely vital for production usage. (Voldemort does this well, for example.)
dynamodb  aws  ec2  testing  integration-testing  unit-tests 
september 2013 by jm
Divide and Concur « Code as Craft
Etsy's interesting approach to managing a large test suite, annotations marking potentially troublesome integration tests: "flaky", "database", "network", "sleep" and "slow".
testing  etsy  php  test-suites  annotations  integration-testing 
february 2012 by jm

Copy this bookmark: