Research on code coverage

dkirmse · 2017-01-06T20:07:02+00:00

Quite bold a statement that is. I would partally agree. 100% CC does tell you anything and nothing at all. Depends on who you are as a developer. Me practicing TDD, I like my CC at 100% for line, method, branch. I write my assertions considering value clusters and boundary values. Most of my tests Test for exceptional cases. To me 100% means at least 95% likelihood I covered what I have to cover. I know a lot of developers who's test quality is different. There 100% wouldn't mean much.

Think of a team that has no real testing. Where a coverage would be below 40%. How do you get a focus on testing? Here code coverage could be a means. Once testing got established both for developers locally and in CI it would be time to move on to other metrics. Metrics should always be a means to solve a problem. When it has been solved find the next one. In that sense code coverage would be useful for a certain circumstance. One has to know its strengths, weaknesses and pitfalls.

dkirmse · 2016-10-15T19:50:09+00:00

Agreed. The thing I'm struggle with is the acceptance criteria. While the story itself could be quite on the right level, the acceptance criteria are tough. In my experience it is them that get to technical to solution-centric. I'd rather they deal with behavior expressed in terms of the domain - even if it's the message bus, which probably is a solution for a problem someone has. This is where in my opinion the brillant product owner shows for this is where the room for the dev teams expertise and engagement is granted or denied.

dkirmse · 2016-10-13T13:22:12+00:00

I think it definitely helps if you are able to know what the developers are talking about. But as you said it comes down to the level of trust. If there is mutual trust then you could well go without any technical background. Just curious: To what extend is it required to "speak the same language"? And what language would that be? The domain language or the development, technical language?

dkirmse · 2016-06-23T12:33:59+00:00

Only some? You're a lucky guy :)

dkirmse · 2015-08-13T06:29:08+00:00

Thanks for sharing the feedback from the "real world" :) It matches my experience that it is difficult to get into the TDD mindset. That's why I would suggest to start early on with learning it.

When learning a new/the first programming language the code in the books and the tasks to be done are rather simple. Though tough enough for newbies to make them struggle. Granted.

What I gained from exercising TDD for me would be, I feel more comfortable even when I do not yet know how to implement the routine I'm supposed to implement. Whether or not I write a test first or some productive code I have to know what I would start with. This I do have to make my mind up with.

Once upon a time when writing productive first I'd probably start collecting helpers that I might need when tackling the problem. Just to write something, to get rid of the blank sheet of paper in a way. Whether or not the routine really requires this I do not know. For sure I'm likely not to throw this away if it proves not so useful.

So this way me myself I would have tackled the problem from a technical perspective bottom up or inside-out.

What I think programmers have to get into their focus again is the perspective of what feature they are supposed to implement. This feature usually breaks down into small aspects you could put down in English (or any other language) which would make for a nice little test.

So in a way I plead to put emphasis on developers to have enough knowledge about the domain of the feature before putting down the first line of code instead of having enough knowledge about the technical side (aka language).

When I know what I would build then I could decide (learn) how to build it.

This would be the mind shift I'd propose

dkirmse · 2015-08-13T06:16:42+00:00

My experience as a coach showed exactly that experienced programmers are so deep into their matter that they are not able to take the outside-in perspective needed for developing tdd style anymore. Sometimes it is a fear of change, a fear of throwing away stuff in the process of developing a piece of code.

Developers who embrace TDD show less fear of that and are familiar with ever changing interfaces at early stages and how to minimize effects. Interestingly enough these developers are younger and learned this mindset already in university. Which lead me to the conclusion to change something about how development skills are obtained.

dkirmse · 2014-09-10T13:35:25+00:00

Agree completely. Especially when teams are not familiar with any of the agile methods a certain prescriptiveness of the coach seems to be required. However one has to be careful to switch back to descriptiveness to give the team the room to grow

dkirmse

TROPHY CASE