Topics

Featured in Development

Peter Alvaro talks about the reasons one should engage in language design and why many of us would (or should) do something so perverse as to design a language that no one will ever use. He shares some of the extreme and sometimes obnoxious opinions that guided his design process.

Featured in AI, ML & Data Engineering

Today on The InfoQ Podcast, Wes talks with Katharine Jarmul about privacy and fairness in machine learning algorithms. Jarul discusses what’s meant by Ethical Machine Learning and some things to consider when working towards achieving fairness. Jarmul is the co-founder at KIProtect a machine learning security and privacy firm based in Germany and is one of the three keynote speakers at QCon.ai.

Book Excerpt: Continuous Integration means Continuous Testing

Continuous Integration (CI) is a basic Extreme Programming (XP) practice, but it is also used by teams that would never consider XP for their work. Martin Fowler has pointed out that, at this point, it's become an essential part of any competent software development activity. In their book Continuous Integration: Improving Software Quality and Reducing Risk, Paul Duvall, Steve Matyas and Andrew Glover aim to help teams make this important practice a "non event" on their projects - something that happens unobtrusively and as a matter of course. When successfully implemented, CI ensures that any individual developer's work is only a few hours away from a shared project state and can integrated back into that state in minutes. InfoQ presents a pdf download (14MB) of Chapter 6: Continuous Testing, which presents strategies for writing the different kinds of tests required to ensure system quality.

Testing is a key area for CI improvement, since the bulk of an application's build time is usually applied to running tests. Poorly constructed test suites can cause build times to bog down, at which point teams start to circumvent their own agreed-upon CI practices just to recapture the time they need to code. These shortcuts increase the likelihood of "red" (broken) builds, and can lead to a "broken windows" scenario in which it's impossible to judge code quality because the build runs "red" more often than not, increasing the risk of serious production flaws, and provoking the addition of lengthy pre-release testing that delays deployment.

In this chapter on testing the authors describe the following topics and the relationships between them:

Automate unit testsAutomate your unit tests, preferably with a unit testing framework such as NUnit or JUnit. These unit tests should have no external dependencies such as a file system or database.

Automate component testsAutomate your component tests with unit testing frameworks such as JUnit, NUnit, DbUnit, and NDbUnit if you are using a database. These tests involve more objects and typically take much longer to run than unit tests.

Automate system testsSystem tests are longer to run than component tests and usually involve multiple components.

Automate functional testsFunctional tests can be automated using tools like Selenium (for Web applications) and Abbot for GUI applications. Functional tests operate from a user’s perspective and are typically the longest running tests in your automated test suite.