Between unit testing and functional spec

Excellent info! Vikas! http://vikasnetdev.blogspot.com/2006/07/faq-fit.html

You convinced me that Fit should be considered as one of the basic programming techniques – yes, I tend to go to "extremes", and a pun is intended :-)

1. In a lot of tiny projects, there are no business analysts (BA). The responsibilities of BAs are carried out among programmers, project managers, and power users. Project managers are not very technical; and they do not know domain very much either. So, it is crucial that power users can use Fit-tables.

Now, the key is how to steer power users to use Fit-tables. After reading your post, I put more thinking on it.

Currently, I am using documents containing story-board mockups plus buttons’ behaviors. It is a common sense approach of "functional spec"; if you really want some names, Alan Cooper’s “forms and behaviors” http://www.cooper.com/content/why_cooper/the_process.asp is a good source. I usually also intentionally “leak” the major (but not all!) database tables as the “key concepts” to users, so that I can verify the 1-1, 1-m, m-m concepts directly. Note that I never show the whole ER diagram to them, because that would scare them or confuse them. Also, totally contrast to what is in most OO books, I learnt not to talk about “objects” at all to users; they do not care, and they get confused by those anthropomorphical talking quickly. OK, I know my point is controversial; but I know I am very good at OO; and I also attended those official, intensive training courses from well-known companies, a few times; so, I know what I am talking about; and, I am not against using OO concepts within developers, or, even with some Business Analysts.

---- Note: the source of using OO (“domain model”), instead of ER, in functional spec/stories/use cases, is the assumption of the separation of code design and database design. That assumption is obsolete long time ago. Nowadays, in all tiny or small projects, developers, instead of DBAs, are responsible for database table designs. For larger projects, in the original analysis/design phases, it is also developers, not DBAs, who are doing the database table designs. Nowadays, because databases are so “easy”, and the coding is also so “easy”, database table design is totally developers’ responsibility; DBAs responsibilities are more for production issues and performance tuning. Again, I understand this point of view is controversial;what I am talking about is perhaps from bad habits or the long time braining-washing of "worst practices" (but to be fair to myself, I know it is the “reality practice” of at least more than half of the projects in the world) , so, read it with a critical mind ;-)

Obviously, the "functional spec" or “forms and behaviors” is also the “stories” (XP) or “use cases” (UP); just that it emphasizes that the mockups are crucial here – I know, it is a sharp contrast that in development, everything is around the unit tests, which is totally anti-UI – it seems that the value of Fit is that it provides a bridge between this yet another outrageous impedance mismatch.

Now, here is the fun part: in the “buttons’ behaviors” section, we have already used a lot of tabular format; now, by FIT, we can make those tables directly testable. We have two documents now; but that can be get used to easily.

So, after all, FIT can fit in very easily. Thank you, Vikas for posting this.

2. Another smaller issue (but still crucially though): it seems that it can be run by an open source program that is “tiny” (i.e., if I want to, I can get into it and fix or “customize” it in a few days, instead of a few weeks).

---- If possible, it should be able to be run without the web. In the cases that we do not have business analysts; or, business analysts do not care to run Fit by themselves, that would make things even closer to ordinary unit testing.