It’s been a couple months that we renewed a few aspects of our experience, as developers, here at DNSEE, introducing a few practices that common software factories ignore: we – and I – don’t know if these practices will always be fine for our daily job but, as far as we saw, things are just working fine.
1 2 3 4 5 6 7 8 9 10 11 12 13
thus you – developer – are not always required to write a test for every feature in the project: this task is done by the PO, helped by you ( while experienced PO may not need your help, at all ).
The scope of the tests
We usually develop projects with the RAD framework symfony 1.4, which comes bundled with Lime, a ( limited ) unit and functional testing tool: we are now testing features wanted by the stakeholders of the projects with Behat, and functionally testing those ones who require pretty complex DOM checks.
Unit tests cover almost every class which are dangerous not to test: apart from these classes, we also use unit tests to test forms, because a form can behave in different ways based on the input it receives: since you should tests those forms in a functional test, submitting several times the form and veryfing the expected output, functional tests become very slow ( a test-suite is slow, IMHO, when it lasts more than 10 minutes ): thus, we decided to unit test the forms ( in symfony 1.4, they all are objects, so easy to unit test ).
Unit testing forms means faster test-suites, since, in functional ones we only test the happy path, which is submitting good values to the form and veryfing the expected successfull output ( thanks Jacopo Romei for suggesting it ).
We started using Capistrano through Capifony, the automatic-deployment utility written for symfony 1.4: at every commit the developer is responsible of generating the proper doctrine migrations and deploy ( deployment usually takes… one bash command ) with
Since we also wanted to ease the process of updating the issue tracker and BDD reports, we created a script that launches the test-suite ( BDD, functional, unit, integration tests ), deploys with Capifony and publishes the BDD reports on Alfresco, the platform we use for sharing documents: it’s a dummy bash script, similar to this one.
It’s not hidden, we are trying to use SCRUM) as a framework for our processes: I prefer XP, mainly because there’s no CrapMaster and the whole team is connected ( I repeat it, whole team ) but things seem to work fine.
Our first ScrumMaster, Andrew, tought us the basics of the framework and helped us in becoming a SCRUM team; as he left, Daniela started following the team as product owner, giving some hints to David, which is trying to act as the new ScrumMaster, and the rest of the team.
In the meantime, we are also continuing the effort of developing our CMF, ConGoW, but things are going a bit slow and we are keeping it inter nos until we will have a usable version of the framework.
The effort of exposing ourselves to the OS world is paying off now: a few customers are coming asking for mainly-technical works, like refactoring an old-style architecture or re-writing their webservices.
If you find this point strange to mention, consider that DNSEE is a leading agency in communication and creativity, thus not born with a technical focus: what else do I need to say? Alex, our CTO, has done a tremendous work.
I’m pretty sure that lots of guys who read this blog are aware of this tecniques/processes, so this won’t be a groundbreaking discovery: my intention is to share how we try to manufacture software in DNSEE and hear, from y’all, some other points of view.