blog.rimann.org

During the last days, I developed some code for the testing framework within the oelib extension for TYPO3. For this part of functionality, we went some new ways for development workflow that led me to some thoughts.

That's what I realized during and after that work:

Having a plan is important

Seems totally logical - but isn't! Earlier, we've just grabbed bug and/or feature requests from the bugtracker and started coding. Later when an other developer within the team looked through the code during the code review, we (sometimes) found out, that the whole structure/architecture of the code in the current patch is not perfect.

For the testing framework we had a discussion on the phone. It was more or less a short 15' brainstorming session about the functionality. We talked about what should be implemented and how this should be done.

After that initial discussion, it was much easier to start coding as the structure was defined and I could concentrate on coding the real stuff.

Unit tests are great!

Since I really started working with unit tests, I started liking them! Sometimes it may look like "overkill" to write unit tests for small methods. On the other hand they save much work on testing when the code gets refactored later.

And it's geeky to see all the tests passing and resulting in a green result list :-)

Test first - I don't like it

There is a technique called "test first" which stands for writing the tests at the beginning and then starting to implement the methods that should be tested later.

Of course it's cool to see the number of failed tests getting smaller and smaller every time you implement something and re-run the test suite. But still I don't like it.

I prefer to have a somewhat detailed list of features and then start coding while following this list of "must-have-features" (This requires a detailed battle-plan, see above).

After that, I then start writing the tests - following the exact same list of features. If everything goes well, the tests run through and everything is ok. And if not, there must be a bug in my code - and I can start fixing it until the test runs through.

Test first ^light

That's something I invented right now: I call it the light version of test-first. It's about writing the documentation as the first step of development of new parts or even completely new extensions.

I see some pros on this: When you write a detailed documentation, you need to know what exactly you are going to develop. This includes also to think like the end-user that will use this tool later. What will he think when he sees the frontend? What steps will it take him to finish the task he wants to do? The big pro is that you develop a plan that enables you to write the documentation.

But there are some disadvantages, too: Especially for TYPO3 where extensions have no plain-text documentation (it's OpenOffice text document at this time). This way, it's not possible to write the documentation and then merge it with the current version in the SVN repository. As OpenOffice files are binary, SVN can not handle merges on these files. For one-man projects that shouldn't be a big issue. But for teams that collaborate and everyone works on the same file, collisions would be pre-defined...

StatSVN can motivate

We recently had a more or less silent phase regarding the further development of the Seminar Manager, oelib and the other extensions. Then I installed statSVN to see what's going on within our subversion repository.

StatSVN provides one list that's called "Developer of the month". And even if I din't install statSVN with this result in mind, it's great: StatSVN motivates me to write code, to bring up patches for bugs and to get this code into the SVN repo. And maybe of getting the "Developer of the month award" :-)

What did you find out about coding workflow? Please share your knowledge in the comments.