More On Designing TAF Layers

If you decide not to design some parts of TAF at the very beginning, you are guaranteed to have HUGE problems in the long run. Do not deceive yourself by thinking that the future is far away. Issues that stem from poor design can turn out to be nasty. It will not be just 'a bit expensive' to get rid of them. Failing to design TAF layers properly may render the whole system virtually unusable. I always invest a lot into the initial design, and I have never regretted it. It saved me time, effort and sanity.

Test Framework Is A Software Product

When you intend to write a test framework you need to remember the following:

- test framework is a software product, which means everything that applies to a commercial product, also applies to a test framework;

- test framework is not less important than the software under test, it is actually more important (and sometimes more complicated) than the software under test.

Test frameworks are created to help you check if you still meet the requirements (and to do it with less effort than manual test requires). Because if you do not meet the requirements, you do not achieve the project goals and|or create more problems than you solve. For instance, you spend enormous amount of time on manual defect management and dealing with architectural issues when it is too late and too expensive.

So if you decide to create a test framework, you have to:
-- define the requirements;
-- define priorities for the requirements;
-- define stages of maturity (what is to be implemented first and what next);
-- find out how much resource you have (time, technical knowledge, congitive ability, ability to delegate);
-- build the schedule of implementation (preferably by using a Gantt diagram).

Otherwise, I am sorry to say, your test framework will be nothing but a cost.

-------------------------------

Related posts:
Real Life Requirements For A Test Framework
More On Designing TAF Layers

Coding challenge - Repeated string

When I popped out for some food today it dawned on me that there are basically two type of tests. First try to find out if you're good at drilling and memorising, and second one is looking for an ability to create your own solution. Sadly enough, first type claims to the the second type, but never vice versa.

My version of code is below and original task can be found here: LINK

Coding challenge - Jumping on Clouds

Here is another one. Didn't use collections this time.

Original task is here: LINK

My version is below

Coding challenge - Sock Merchant

I hate test tasks so much I spend four hours out of five to think why I hate them so much. This time I came up with the following list of whys:

-- expectations are never clear and when they are clear they are clearly about knowing rules for the game, not actual solving something from the scratch, to be successful you need to be familiar with known working solutions, not work on your own;
-- ruminating about what your interviewer brain processes is very distracting, cause practice proves that they may be thinking lots of things, almost all of them not in your favor.

What would be better, array or collections? If you use array they will think you don't know collections. If you use collections they'll think you have a habit of over-complicating things. And if you use for or if  they'll think you've worked with legacy for too long and sustained irreparable brain damage.

Well, anyway, original task is here, and my version of code looks like this: