John
2016-04-13 16:20:06 UTC
So I was reading a lot about Cucumber, and have been using it for a while.
I have something that bothers me and I would like to hear your opinions.
Let's say I have an app the matches two people by comparing their online
profile. My feature file would like like so:
- I can create a profile
- I can view others profile
- When match is happening I get a notification
- I can check my previous matches
etc.
This part is crystal clear and does benefit from speaking behavioral. But
what if I want to test the matching system? Is very complex system, and
there is a lot of data connections within in. For example:
*X, Y, Z, 1, 2, 3 *will match *X, Y, Z, 1, 2, 4*, but will not match *X, Y,
Z, 1 ,3 ,2*. Why? Because your profile is marked as 'Male', because your
age is different, because your don't have shared friends and other stuff.
So technically, I can try to sit down and ask myself - what the above
combination means to the stakeholders? Can I break them down into smaller
parts?
This is tough thing to do. Because we write feature file retroactively -
It's require a lot of understanding in how the system work and what's the
data correlations are. Even if you do manage to do it, steps end very
verbal, or you have to add a big Cucumber table with data into it the
feature file become monstrous and not readable.
So very complex systems that are very data oriented always felt better
working on a Data Driven unit tests framework that support reading data
from external CSV, has better support in dynamic data tables etc.
So, back to the question - is BDD enough? Is it enough to use JUST
cucumber? or Cucumber is mainly an acceptance tests tool and it should be
used with more traditional unit/component/ testing tool?
I have something that bothers me and I would like to hear your opinions.
Let's say I have an app the matches two people by comparing their online
profile. My feature file would like like so:
- I can create a profile
- I can view others profile
- When match is happening I get a notification
- I can check my previous matches
etc.
This part is crystal clear and does benefit from speaking behavioral. But
what if I want to test the matching system? Is very complex system, and
there is a lot of data connections within in. For example:
*X, Y, Z, 1, 2, 3 *will match *X, Y, Z, 1, 2, 4*, but will not match *X, Y,
Z, 1 ,3 ,2*. Why? Because your profile is marked as 'Male', because your
age is different, because your don't have shared friends and other stuff.
So technically, I can try to sit down and ask myself - what the above
combination means to the stakeholders? Can I break them down into smaller
parts?
This is tough thing to do. Because we write feature file retroactively -
It's require a lot of understanding in how the system work and what's the
data correlations are. Even if you do manage to do it, steps end very
verbal, or you have to add a big Cucumber table with data into it the
feature file become monstrous and not readable.
So very complex systems that are very data oriented always felt better
working on a Data Driven unit tests framework that support reading data
from external CSV, has better support in dynamic data tables etc.
So, back to the question - is BDD enough? Is it enough to use JUST
cucumber? or Cucumber is mainly an acceptance tests tool and it should be
used with more traditional unit/component/ testing tool?
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.