Nikolas Martens hat am Wochenende auf der FrOSCon in seinem Vortrag „The Pyramid is a lie“ vorgestellt wie Tests richtig laufen sollten. Ich möchte nun hier nochmal die Erkenntnisse aus dem Talk darstellen. Die Slides von Nikolas findet man hier.
Last week I had the chance to attend an Agile Developer Skills Workshop in Berlin.
The 3 day workshop is, next to a Scrum Master or PO Certification, a prerequisite for the Certified Scrum Developer, short CSD.
I was very excited about the ADS workshop and I found it an intersting approach to hold a workshop which focusses on developers rather than on the management side of scrum. Especially as in my experience all the other scrum workshops mainly concentrate on the rituals, artefacts and organisation of Scrum, without giving answers on how to develop high quality software.
Nearly every PHP project comes up with a great set of tools to assure the quality of source code; unit tests are a no longer a „nice to have“ feature, they are common components in new projects. While unit tests help you to provide solid interfaces and proof the functionality of a certain method, there is a long list of tools that check the quality of the source code itself with many different metrics. Each of these mentioned tools reports its results into a XML file, which can easily be interpreted by a continuous integration server like Jenkins. The benefit is enormous: After every commit to your version control system your continuous integration server triggers the execution of the tests and the source code quality analysis and shows the result in meaningful diagrams. As a developer you get a direct feedback and you can make a prediction on the status of the entire project, because if even the smallest units work fine, there is a good chance that the whole system runs stable.
Weiterlesen
Testing software whilst ongoing development seems to be a boring job containing a lot of reoccurring
tasks.
You might end up entering the same test data, most of the time not
really context relevant one like for example „foo“ or
„bar“, into the same web-forms and get the feeling of doing
work that is not really useful for your daily developer business.
When timelines get closer and the development gets harder, these tests
are tending to be less important than the developing work on the
product.