Pinboard (jm)
https://pinboard.in/u:jm/public/
recent bookmarks from jmWrite tests. Not too many. Mostly integration. – kentcdodds2019-02-01T11:32:49+00:00
https://blog.kentcdodds.com/write-tests-not-too-many-mostly-integration-5e8c7fff591c
jmintegration coding testing unit-tests integration-tests system-testshttps://pinboard.in/https://pinboard.in/u:jm/b:b2c5531ba011/How do you populate your development databases?2018-11-08T14:56:53+00:00
https://dev.to/jaredsilver/how-do-you-populate-your-development-databases-e8e
jmdatabase data testing system-tests devhttps://pinboard.in/https://pinboard.in/u:jm/b:286cf87eafef/Testing@LMAX – Time Travel and the TARDIS2016-11-21T11:29:55+00:00
https://www.symphonious.net/2014/04/01/testinglmax-time-travel-and-the-tardis/
jmlmax testing system-tests acceptance-tests tests timehttps://pinboard.in/https://pinboard.in/u:jm/b:0c1c1fc4c02e/Fake Time2016-08-06T08:19:45+00:00
http://c2.com/cgi/wiki?FakeTime
jmWhen 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-testshttps://pinboard.in/https://pinboard.in/u:jm/b:869d93286a1c/Testing@LMAX – Aliases2015-06-08T10:20:49+00:00
https://www.symphonious.net/2015/06/08/testinglmax-aliases/
jmCreating a user with our DSL looks like: registrationAPI.createUser("user");
You might expect this to create a user with the username ‘user’, but then we’d get conflicts between every test that wanted to call their user ‘user’ which would prevent tests from running safely against the same deployment of the exchange.
Instead, ‘user’ is just an alias that is only meaningful while this one test is running. The DSL creates a unique username that it uses when talking to the actual system. Typically this is done by adding a postfix so the real username is still reasonably understandable e.g. user-fhoai42lfkf.
Nice approach -- makes sense.
]]>testing lmax system-tests naming codinghttps://pinboard.in/https://pinboard.in/u:jm/b:f785d985512e/Making End-to-End Tests Work2015-05-08T10:43:28+00:00
https://www.symphonious.net/2015/04/30/making-end-to-end-tests-work/
jmend-to-end testing acceptance-tests tests system-tests lmaxhttps://pinboard.in/https://pinboard.in/u:jm/b:2f546a981ba9/moto2014-05-09T15:47:48+00:00
https://github.com/spulec/moto
jmpython aws testing mocks mocking system-tests unit-tests coding ec2 s3https://pinboard.in/https://pinboard.in/u:jm/b:1ca94eae1159/TDD is dead. Long live testing2014-04-24T14:41:16+00:00
http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html
jmTest-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 mockshttps://pinboard.in/https://pinboard.in/u:jm/b:1b88f6f761dd/