• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Question for Kostis: code-first approach Vs Test-first

 
Ranch Hand
Posts: 238
1
Python Ruby Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Kostis

There’s some dispute about how exactly tests should be written. While the TDD process itself insists on the test-first approach, I personally think that both ways are applicable in different circumstances
What would be your advise on this?

Regards
Sundar
 
Author
Posts: 16
5
Spring VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Sundar

Yes I agree with you. TDD is a suggestion and not a strict rule. Rules are great for beginners, but experts know when to bend or break the rules.

I have seen companies who think that TDD is the only way forward, often following it in a religious manner without truly understanding its goals.
I think that both ways are applicable.

Sometimes I write the code first and then the tests if it makes sense. Sometimes I write multiple tests that succeed directly after the first run.

A particular area where I think TDD is not that helpful, is when I am prototyping something. There are no clear specs so it is very hard to write unit tests if the details are blurry.

Finally, while TDD helps you write testable code, a Java guru can write testable code (i.e. with good design, SOLID principles, IOC etc) without actually writing any unit tests first.
Not all people can do it, but there are some who can (and no, I do not claim I am that good)

I think TDD has great value in big teams where team members have uneven Java knowledge. But blindly assuming that TDD is always the solution is obviously wrong.

So yes, both ways are applicable in different circumstances exactly as you say.

Kostis
 
meenakshi sundar
Ranch Hand
Posts: 238
1
Python Ruby Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well said Kostis.

Though unit tests have become a common technique in the developer community, the true payoff of a TDD approach is significantly less common. Many developers get value out of adding suites of tests that cover regression issues, but the focus is often on adding the tests after the code and sometimes days or weeks after the production code was written.

Spock sprang out from the BDD movement , At the same time , Another key framework which came in the Ruby world was RSpec and it took off over time,Where does Spock stands comparing to RSpec /Cucumber in terms of enabling developer productivity ,Richness,...
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Great reply, Kostis.

Even folks like Kent Beck, Ron Jeffries, and Ward Cunningham admit to not doing TDD always or strictly following red-green-refactor when they do. Neither do I.

Like Beck, Jeffries, and Cunningham, however, I am less comfortable writing code without having at least a few tests to guide my design thinking. I also find that not doing TDD tends to slow me down because I have to be more cautious and conscious of the ramifications of new changes I introduce that are not covered by tests.

The only thing I'd add to "TDD is a guideline" is that it should be the norm rather than the exception. Don't use the fact that it's OK to not do it all the time as a way to justify not doing it most of the time or at all. That is not a "loophole" that you can use as a justification for not doing TDD but rather you should take it as a caveat against dogmatic practice.

In most cases where developers try to weasel out of doing TDD "because it's hard to write the tests first," it's either because they are trying to test too much all at once, trying to test at the wrong level, or simply did not refactor enough in the first place to make their code more testable. Once I address these issues, I can usually show that they could have absolutely done TDD or at least more of it.

All that said, code produced when doing TDD properly tends to be of higher quality than code that was written without doing TDD. Likewise, refactoring and tests written after the bulk of the code has been written tend to be less useful than refactoring and testing that is done as you are writing the production code.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

meenakshi sundar wrote:While the TDD process itself insists on the test-first approach


I don't know if that's really the best way to put it, especially the "insists" part. That's kind of like saying swimming insists on an "in the water" approach. Just as historical note, the practice was first referred to as "test-first programming" and the term "test-driven development" later supplanted it. Some even referred to TDD as "test-driven design" because of the emphasis given to design thinking when doing TDD properly.
 
Kostis Kapelonis
Author
Posts: 16
5
Spring VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Sundar

I don't have much experience with the Ruby world, so I cannot really comment on RSpec. As far as I can remember, RSpec is one of the frameworks that have influenced Spock, so any similarities might be on purpose.

Regarding Cucumber.
I like to think Cucumber as the full BDD solution. By full, I mean as a whole process where devs, testsers, analysts, PMs are involved and you all follow the "cucumber way" of doing things.
If you are lucky to work in a big company and have convinced your whole team to use/learn Cucumber, I really envy you.

But for simpler cases (e.g. startups), using Cucumber just within the development team is not that different from using Spock.

So I would say that Spock is a lightweight BDD solution (geared towards developers) while Cucumber is the heavyweight BDD solution (geared towards everybody)

The comparison comes down to people instead of technical differences.

I have tried in the past to convince my company to use cucumber and failed because not all people were onboard.
With Spock things are easier, since you get value even if it is just used by developers (parameterized tests, mocking/stabbing, extra annotations etc)

Kostis
 
meenakshi sundar
Ranch Hand
Posts: 238
1
Python Ruby Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for insight Kostis.

In my knowledge Spock is very powerful and it is very expressive and easy for our developers to learn ,work and quickly leverage.
But is very developer-centric.

Pairing developers with testers and BAs might solve the developer centricity of Spock and move towards more agile and BDD
What would be your take on that?.

Regards
Sundar
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First, I don't really buy that it's "developer centric" -- yes, you'll need a developer to actually write out the code but the tests are very readable, even by non-developers.

Second, let's say we accept that it's "developer centric" -- I don't really see that as a bad thing. My wife's development team at a major bank uses Cucumber but the way they have their process is messed up and I think that using the Gherkin language can actually encourage the kind of organizational anti-pattern they have. Here's the rundown of how they do "BDD":

1. Business "Scrum Master" (really their Scrumified term for Business Analyst) will write up the requirements in JIRA, using Gherkin syntax.
2. Developers copy the Gherkin from JIRA and paste it into proper .feature files
3. QA refers to the "single source of truth" JIRA issue where the original Gherkin specs are and create their own test cases, many of them manual.

You may be thinking, "WTF?!" which is exactly what I said when I first heard of this cockamamie process. But this is the kind of thing that happens when people just want to keep doing things the way they're used to doing them (in the old traditional way) and still use these new-fangled gadgets like Cucumber and Gherkin so they can say they are "Agile". It's hard not to be cynical about Agile and xDD when these kinds of things happen in Fortune 100 companies like the one where my wife works.

At least with Spock and the right push from the developer side, conversations about the tests will actually happen around the Spock tests. This will hopefully make it abundantly clear how ridiculous the type of handoffs I describe above are and help people realize that the utility in BDD is really in the type of conversations that it sparks between developers and product owners and QA/testers. Cucumber/Gherkin can also do that but I think the separate steps of writing and wiring up the feature specs can encourage work silos and handoffs.
 
Kostis Kapelonis
Author
Posts: 16
5
Spring VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello both.

To Junilu
Yes I know the situation you describe. I call it the "company waste". It is the extra needless effort that happens in big companies where people do not think outside of their roles.
I try to avoid office politics, and frankly sometimes I just accept the situation (until I change company that is). I don't think that this problem is particular to cucumber. It always happens when new tools are "adapted" on an existing
process, rather than changing the full process from scratch.

If you ask me, I would prefer it if business analysts wrote directly the skeleton of Spock tests (i.e. the given, when,then descriptions) and then devs just filled the code. This way everybody would talk about Spock tests as you suggest.
But is this really realistic? Do you know a company that does this? :-)

To Sundar:
Well, I believe that the human factor is more important than tools. If all the team members work together (regardless of their role) and everybody agrees on a sound process, then tools are secondary.
The problem with developers and testers/analysts is that the former usually think of a system from inside/out while the latter think of the outer shell only (they don't care about internals)
I am always amazed with testers that find strange bugs in my code because they have a different way of thinking than me (when I was writing the code).
Yes, as I already mentioned it would be good if the whole team revolved around the Spock tests. At least in the companies I have worked so far, this has never been the case. :-(

Kostis
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Kostis, I can't speak for entire companies, not even the one I work for, but I can confidently say that there are teams out there that will find Spock an improvement over Cucumber because there is no extra step to generate code and fill in the wiring. These teams would not have business analysts but have developers working directly with users and product owners. One of the teams I mentor has started using Spock and Geb and it has helped the Devs and QA work even more collaboratively than they already were before.
 
Kostis Kapelonis
Author
Posts: 16
5
Spring VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes

If the team does not have business analysts, then maybe things are different. :-)

Glad to learn that you are already using Spock and Geb and that it has improved the way you work!

Kostis
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic