Here Kyle provides a look at test automation in Python. Python is continuing to show strong growth in general language adoption and jobs markets. Python’s urge for simplicity and pragmatism has brought about a vibrant and supportive community, making for a powerful language with a shallow learning curve. It’s an excellent language for test tooling and Kyle hopes to give you a simple overview to allow you to build a practical, maintainable and scalable test infrastructure for your client facing and systems level integration test needs.
Kyle will give you an overview of pytest, a simple open source test framework, which contains very powerful features to help you construct concise tests quickly. Kyle will show you the design structure implemented at FanDuel, the leading daily fantasy sports company in the US and Canada, that aims to foster stability, ease of use and ease of contribution.
Even if you currently have a solution for your project or organisation, Kyle hopes you will have takeaways from the approaches above and wise tokens of hard lessons learned in test automation efforts.
1. Introduction of speaker and the organisation the speaker belongs to.
2. Why Python might be a good language choice for test tooling.
3. Intro on pytest and its features.
a. pytest test composition in comparison with standard module unittest (JUnit style).
b. Assertion failure introspection.
c. Test setups and teardowns as modular fixtures (dependency injection).
d. Examples of useful Pytest plugins; pytest-xdist for test parallelisation and pytest-selenium that provides support for running Selenium based tests.
4. Test Infrastructure at FanDuel with pytest.
a. Overview of FanDuel client facing and integration level test repositories.
b. FanDuel use of shared pytest fixtures across its test infrastructure and the advantages of homogeneity of test setups.
5. A quick fire of 6 lessons learned in test automation.
a. Test Infrastructure should be lightweight as managing large scale functional test suites is difficult, costly and can become detrimental to your organisation.
b. If there are areas of the system that you can afford to react and fix issues quickly, test automation is probably not the best strategy to take. There are many ways you can mitigate risk for these features; investment in good monitoring is one of them.
c. Test automation, like testing in general, is best when you have good investment in testability of applications under test. Testability can also affect not just your ability to test but the speed of your tests; slow tests can be harmful.
d. Don’t treat test automation as the automation of testing. Treat it as making automated checks on critical parts of your system.
e. Have zero tolerance for test “flakiness”. Every failure should be taken notice, if you are plagued by test flakiness then genuine failures become diluted.
f. Peer code reviews, like on “standard” codebases, on tests are invaluable.