[
http://jira.dspace.org/jira/browse/DS-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Donohue reassigned DS-536:
------------------------------
Assignee: Stuart Lewis
Assigning this issue to Stuart Lewis for initial review/analysis. Is this
still relevant (and complimentary) to the current DSpace Unit Testing framework
developed in GSoC?
Here's today's discussion for our DSpace Developer Mtg:
[20:05] <tdonohue> Functional Test Framework for DSpace :
http://jira.dspace.org/jira/browse/DS-536
[20:06] <tdonohue> Any thoughts on this? Is this obsolete cause of the Unit
Test Framework in Trunk now?
[20:07] <mhwood> It appears to be a different sort of testing.
[20:07] <tdonohue> (obsolete is wrong word -- obviously functional testing
different then unit testing)
[20:07] <richardrodgers> It should at least be evaluated against that work , I
think
[20:08] <tdonohue> Ok -- will assign DS-536 to stuartlewis (as he mentor for
Unit Test GSoC project) to get his feedback. We'll revisit later
> Functional Test Framework for DSpace
> ------------------------------------
>
> Key: DS-536
> URL: http://jira.dspace.org/jira/browse/DS-536
> Project: DSpace 1.x
> Issue Type: New Feature
> Reporter: Scott Phillips
> Assignee: Stuart Lewis
> Attachments: Dspace-1.5.2-FunctionalTest-V2.patch.txt,
> DSpace-1.5.2-FunctionalTest.patch.txt
>
>
> The Texas Digital Library has been focusing on testability for our projects.
> Since DSpace is related too or part of most of our projects we've been
> looking for a way to increase DSpace's testability. Traditionally this would
> mean adding unit tests and integration tests. However as DSpace currently
> stands is hard to break it up into individual components that can be tested
> in isolation. You'll quickly find that writing tests for DSpace pull in the
> entire system, plus databases, and a file system. To address this problem
> we've created a simple framework for adding both integration tests and
> functional tests which improve the reliability of our projects. I'm
> interested to see if this is something the greater DSpace community would be
> interested in?
> The goals of our project were to create a mechanism where we could run
> complete functional tests. Functional tests evaluate the entire system as the
> end user would use it, so think of it as opening a web browser and evaluating
> the output - but completely automated. They test everything all together.
> Ideal it would be better to test each component individual, but this is in
> practical for DSpace for two reasons 1) DSpace is highly integrated and
> nearly impossible to separate from the database and file systems, 2) Creating
> unit test for all of DSpace is very time consuming it is simpler to write a
> few functional tests that cover a wide set of features over the whole
> application. It gets you to a point where you can reliably verify the
> software quicker. If you're working on unit tests for DSpace please do not
> let this stand in your way.
> The main concept is to script the install of a test DSpace, with a full
> configuration and setup. Then we start DSpace in an embedded webserver and
> then run through several scenarios just as a normal user would. This tests
> the whole application, using a database, a file system, and a full build. The
> ant script where you normally run "ant fresh_install" has a new target "ant
> test". You pass it a few parameters such as what database to use. The script
> will then run through a fresh install of DSpace into a local /test directory,
> setup some communities and collections, and import some basic items. Then
> JUnit-based tests are run against the embedded webserver using HtmlUnit to
> simplify verifying the HTML output.
> Here is how to run it. After compiling using a "mvn package", cd into
> target/dspace-*-build.dir/ directory. Then run "ant test" you may need to
> pass it some parameters as listed below. Each parameter has a default so if
> you configure you're database connections the same way then it can be as
> simple as running "ant test" without any parameters.
> -Dtest.db.driver="org.postgresql.Driver"
> -Dtest.db.url="jdbc:postgresql://localhost:5432/dspacetest"
> -Dtest.db.username="dspacetest"
> -Dtest.db.password="dspacetest"
> -Dtest.dspace.dir="./test/"
> -Dtest.config="./test/config/dspace.cfg"
> We've used this approach rather successfully for two of our DSpace-based
> projects here at TDL: an ETD submission system called vireo, and a learning
> object repository. These projects haven't moved to 1.6 yet, but I do have a
> patch available for DSpace 1.5.2. Most of the test cases we've created so far
> are specific to the project we're working on. However the patch includes 4
> manakin tests, which are really just an example of how tests work within this
> framework.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.dspace.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
