DbFit fixtures can operate in either "flow mode" or "standalone mode", with flow mode automatically rolling back transactions between tests for repeatability and standalone mode giving the user more control over transaction management; fixtures connect to a database by calling Connect and specify the connection details, and transactions are committed or rolled back by using the Commit or Rollback tables respectively. Fixtures also allow storing values in "symbols" that can be accessed across tables to share data between steps of a test.

1. Database Unit Testing
with
DbFit
Presented by
Md. Babul Mirdha
Senior Software Engineer
Leads Corporation Ltd
Part-II

2. Working mode of DbFit Fixtures
• DbFit fixtures can work in two modes:
– Flow Mode
– Standalone Mode

3. Flow mode:
– a DatabaseTest fixture controls the whole page
and coordinates testing.
– automatically rolls back the current transaction at
the end to make tests repeatable,
– provides some additional options such as
Inspections of stored procedure error results.

4. Standalone:
– In this case, we are responsible for transaction
management.
– This enables you to have more control over the
database testing process

5. Connecting in flow mode
• For Standard Connection:
– Use the Connect method to initialise the database
connection.
– Pass the server (optionally followed by the instance
name), username, password and the database name
as arguments.
!|dbfit.SqlServerTest|
!|Connect|LAPTOPSQLEXPRESS|FitNesseUser|Password|TestDB|
– If you are connecting to a default database, you can omit the fourth parameter.

6. Connecting in flow mode
• For Non-Standard Connection:
– use non-standard connection properties, or initialize your connection
differently (for example, using Windows integrated authentication),
call Connect with a single argument — the full .NET connection string.
!|dbfit.SqlServerTest|
!|Connect|data source=Instance;user
id=User;password=Pwd;database=TestDB;|
– For flow mode to work correctly, the SqlServerTest fixture must be the
first one on the page — not even import can be before it.
– This is why we explicitly specify the namespace.

7. Transaction management- In flow mode
• The current transaction is automatically rolled back at the end of the page.
• If we want to commit it to make changes permanent, put the Commit
table into the page.
• There are no arguments or additional parameters — the table contents
contain just this one word.
• Likewise, you can roll back manually in your test using the Rollback table.
!|dbfit.SqlServerTest|
!|Connect|LAPTOPSQLEXPRESS|FitNesseUser|Password|TestDB|
…
…
…
|Commit|
Or
|Rollback|

8. Connecting in standalone mode
|import|
|dbfit.fixture|
!|DatabaseEnvironment|sqlserver|
|Connect|LAPTOPSQLEXPRESS|FitNesseUser|Password|TestDB|
• Notice that there is no space between
DatabaseEnvironment and Connect — they have to be
in the same table.
• Because we are not using flow mode, we can use the
import fixture as well.
• Most DbFit fixtures are in dbfit.fixture namespace, so it
is good practice to include this namespace.

9. Transaction management-In standalone mode
• Use the DatabaseEnvironment fixture again, but do not specify a fixture argument.
• This tells the DatabaseEnvironment to use the current default database connection, without
attempting to initialise it.
• Call Commit or Rollback in the second row.
|import|
|dbfit.fixture|
!|DatabaseEnvironment|sqlserver|
|Connect|LAPTOPSQLEXPRESS|FitNesseUser|Password|TestDB|
…
…
…
!|DatabaseEnvironment|
|Commit|
Or
!|DatabaseEnvironment|
|rollback|
• It is a very good idea to put this table in a TearDown page for your test suite when you use
standalone DbFit fixtures.
• This will make sure that your tests are repeatable.

10. Demo
Flow Mode
&
Stand Alone Mode

11. More About
Wiki

12. Wiki Actions
Action Name Command To Url
Edit this page url?edit
Create a new page directly
current-url.NewPageName
or
current-url.NewPageName?edit
Test this page url?test
Suite test this page url?suite
Set properties of this page url?properties
See versions of this page url?versions
Refactor this page url?refactor
Search pages from here url?searchForm
Where is this page referenced? url?whereUsed
Debug this test page url?debug
Suite test this page with a suite filter
"passing"
url?responder=suite&suiteFilter=pa
ssing

13. Includes & Informational
Timestamp !lastmodified
Timestamp !today
Help text !help
Contents List !contents
Contents Tree !contents -R
Contents Sub-tree !contents -R[nn]
Contents List - Graceful !contents -g
Contents List - Properties !contents -p
Contents List - Suite Filters !contents -f
Contents List - Help Text !contents -h

14. Include Page
!include AnyPagePath expanded border
!include -c AnyPagePath collapsed border
!include -seamless
AnyPagePath
no border
!include -setup AnyPagePath appears like SetUp
!include -teardown
AnyPagePath
appears like TearDown
| !include AnyPagePath | in a table cell

15. Picture Insert
!img url-to-image-file in-line
!img-l url-to-image-file image left-justified, text wraps on right
!img-r url-to-image-file image right-justified, text wraps on the left
!img[-l |-r] url-to-image-
file
as a clickable link

16. Fixture Symbol
• Symbols are global variables that can be accessed using a simple syntax.
• Symbols are stored in a static collection inside the Fixture class
• To store a value of an output column into a symbol named player, write >>player into the cell.
• To read a symbol value, and store it into an input column, use <<player.
• Think of << and >> as arrows pointing the way.
!|Insert|users|
|username|name|userid?|
|pera|Petar Detlic|>>peraid|
|Mika|Mitar Miric|>>mikaid|
!3 Confirm that IDs are the same as in the database
!|Ordered Query|Select * from users|
|username|name|userid|
|pera|Petar Detlic|<<peraid|
|Mika|Mitar Miric|<<mikaid|
16

17. What is the scope of a symbol?
• Symbols are stored in a static collection inside
the Fixture class.
• so their scope is global from the point where
they are defined until the test runner stops.
• A symbol scope will effectively extend to all
pages executed after the page where it is
defined.

18. Markup variable
Variables
Variable Definition
!define name {value}
!define name (value)
!define name [value]
Variable Usage ${name}

19. What is the difference between variables and symbols?
• Markup variables are processed by the wiki, before running tests.
• Symbols are processed by the FIT engine while running tests.
• Because of that, variables can be used even as a part of cell content.
• you can use a markup variable:
!define Markup {reader}
|StringFixture|
|field|field?|
|acrobat ${Markup}|acrobat reader|
• But this will not work:
|Query | select ‘reader' as Symbol|
| Symbol?|
|>>MySymbol|
|StringFixture|
|field|field?|
|acrobat << MySymbol|acrobat reader|
• Symbols are also available to fixtures at runtime, and variables are not.

20. Wiki and SubWiki
 Wiki:
 A normal Wiki is a collection of pages with a flat structure.
 All the pages are peers.
 You add a top-level page simply by placing a WikiWord on an existing top-level page,
and then clicking on the ?
 SubWiki:
 FitNesse allows you to create Sub Wikis.
 Each Wiki page can be the parent of an entire new Wiki.
 You create a sub wiki page by ParentPage.SubPage (or the shortcut ^SubPage), and then
clicking on the ?
… Wiki
parent
SubWiki 1
SubWiki 2
http://fitnesse.org/FitNesse.UserGuide.SubWiki

21. Sub Wikis and Test suites
• Each wiki (and sub wiki) can have its own
– ClassPath
– PageHeader, PageFooter
– SetUp, TearDown
– SuiteSetup, SuiteTearDown
• Test Suites
– A Test Suite executes all tests in the sub wiki (tree of pages)
– SetUp and TearDown pages are invoked for each page of the suite
– To wrap an entire suite, define the operations on pages SuiteSetUp
and SuiteTearDown
21

22. 22
Wiki
Sub-wiki
Remember to initially create the first page

23. Demo
on Wiki & SubWiki
23

24. WikiImport
• What is WikiImport?
– allows you to import an entire wiki or subwiki
from another FitNesse site.
– All of the pages from the remote wiki will be
copied to your local FitNesse and become part of
your local wiki.

25. • Why should I use WikiImport?
– In a development environment it is most practical to
have a main FitNesse server where all the tests are
maintained and new tests are added.
– However, it is not practical for all the developers to
run the tests on one server.
– Therefore each developer should have a FitNesse
installation in their development environment.
– The test pages from the main server get imported by
each developer so they can execute the most recent
tests against their current code base.

26. How do I use WikiImport?
– Create a page or use an existing page that will
contain the imported wiki.
– Open the properties view of this page.
– There is a form title Wiki Import.
– Supply the URL to the remote wiki that you'd like
to import
– Submit the form.

27. Update imported wiki
• Once a wiki has been imported, it may be
updated at any time.
– Open the properties view of the importing page or
any imported page.
– There will be a button in the Import Wiki section.
– Clicking this button initiate an update of all the
imported pages beneath the currently selected
page.

28. New Edit Buttons -WikiImport
• Once you have imported a wiki, the Edit button will be
turned off and two new edit buttons will be added:
– Edit Locally and
– Edit Remotely.
• Edit Locally
– behaves just like the Edit button that you've used all along.
• Edit Remotely
– allows you to easily edit the page from where the content
is being imported.

29. Automatic Update Option - WikiImport
• Click on the page properties, you'll see a check
box that says:
• Enabling this option will kick off an update for
any test page prior to execution.
• Child pages will inherit this option from parent
pages, which means you need only set on the
root of you test hierarchy.

30. DEMO
Configure & Install & Local Server
Import wiki

31. Thank You!

32. Q & A