Do it, do it. do it well

Even such a small but very useful function saves a lot of time:

procedure assert_equal(expected varchar2, actual varchar2) is
begin
    if expected is null and actual is not null then
         raise_application_error(-20001, 
              'Expected is null'||' Actual '||actual);
    elsif expected is not null and actual is  null then                       
         raise_application_error(-20001, 
               'Expected '||expected||' Actual is null');
    elsif  expected <>  actual then
         raise_application_error(-20001, 
               'Expected '||expected||' Actual '||actual);
    end if;
end;

I believe

With simple, consistent code, change analysis is a breeze. A simple trace through the layers of code with a text-search tool will generally reveal exactly what needs to be changed, and where. A solid test plan will identify what changes broke the system and how, and allow developers to respond appropriately.

No, it’s not fun and not challenging. It’s just good software

http://de.worsethanfailure.com/Articles/The-Mythical-Business-Layer.aspx

For young programmers only...

My little sister has started to study C++ at University.

She is in her second year but in their tasks with big black letters is required to give human readable names to variables and to module code. It's strange... evidently, Pascal at the first year didn't school what is good and how to make job easy first of all to yourself.

I've installed Eclipse to my sister, told about Unit testing a little. It's convenient - to write 5 or 10 lines of code right away tests are running for the checking. It's almost REPL. Testing is a guarantee of not turning program text into one long main function. And if something wrong happens then a couple of key pressing brings you to the debugger to the required place with required data.
It seemed to me she liked it.


I liked to demonstrate the popularity of the approach and was surprised by a huge list of frameworks for tests creation.

As for purpose for student projects there is a tiny file QuickTest.h.

if one is to judge nothing except of three elementary macros QT_TEST(testName),QT_CHECK_EQUAL(value1, value2), and QT_RUN_TESTS is required

P.S The first students C++ sounds in haskell about as follows:

minUncommonWord :: String -> String -> String
minUncommonWord s1 s2 =
  foldl1 (\a b -> if length a < length b then a else b)  
             [x | x <- words s1, x `notElem` words s2]

Say 'IoC' - imply 'testing', say 'testing' - imply...

I'm curious, what if instead of standard {Before, After}[Class] use IoC like declarations for setting a test environment. It's not necessary to use IoC in basic project.. but if an architecture is created with taking in the account the possibility of automate testing then it's most likely that the whole test environment creation can be easy implemented by means of IoC container.

What the fun??

I do not understand.

Why in NUnit and in new Junt instead of simplest agreements of tests naming attributes and annotations are used. All the same, it's very difficult to give more suitable names to SetUp, TearDown and TestSomething methods.

It's hard to agree with an opinion that it's more clear in such a way
[SetUp]
public void SetUp() {}

Class attribute instead of the inheritance from TestCase is great. Now the free place of ancestor a class being tested can get. This is for a case of protected stuff is desired to be tested.

Yes, if in a base class suddenly there are methods which names start with Test and which are not tests themselves then indeed needed things can be selected only with explicit attributes. But this is such a rare case...

P.S. Many other things related to testing I consider are better to implement with attributed.

Links: Powershell in action

I like to study script languages possibilities not from books with artificial samples but during digging real files. More associations remain in memory.

The main thing in the automation is just to remember such a possibility in a right moment.

An interesting article in MSDN Magazine - Light testing with Windows PowerShell

Odd thoughts about testing

Approaches promoted in TDD and something that many people consider to be unit tests are like apples and oranges. In Test Driven Development tests are the way of thinking, one cannot create a program without writing tests to it. To write tests before the code is easy, to write unit tests after it is boring, useless and very often impossible.

All kind of tests are important.

In the traditional TDD there is no loss of time for tests writing by definition.

I'm not used to think by tests. I can assume that it is hard for many people too.

Possibility of automate testing <= Low coherence <= Good architecture.
There is also the reverse chain.

To estimate the coherence from the tests point of view is more easy.

It is not necessary to test everything for early finding problems out. A complex problem that was not found in the low level as the snowball will grow to snow slide and bring dawn the most banal tests of the high level. But before the fixing you'll have to write the test, all the same :)

Tests are documenting errors. Write a test, fix a bug, run the test — it's a guarantee that neither you, nor your mates will trigger this backflash again (that is especially important during the refactoring).

Refactoring without tests <=> you have only yourself to blame

If after the refactoring test is not compiled it's a reason to let your team mates know about changes and ways of moving the old code.

Pre- and post conditions it is not automatic tests (emphasis is placed on any word to your taste). They still need a set of automated scripts.

Unlike homemade solutions unit tests are an industry standard of automated scripts design. There is support from IDE for them.

Tests automate the developer labor, supplement IDE with its specific functionality. Tests highlight the place of errors. Tests simplify debugging. One click and you are in the place of a problem.

There is no good code, there is a code which is easy to rewrite. Tests are one of ways of achievement of ease.

There is a separate chapter in Lingvo - "Easy-to-test"

The main thing is brain, still tests do not guarantee success.

The four large letters IMHO before each peremptory statement about the software development can be dropped only in a personal LJ.

Why should I test the code, if it works all the same?

I'm wild about it:

Almost pseudo code:

databaseAdapter.open(UID,PWD);
databaseAdapter.execute("select 2 from dual");
databaseAdapter.close();
databaseAdapter.open(UID,PWD);
databaseAdapter.execute("select 2 from dual");
databaseAdapter.close();

It falls on the second select.