NUnitLite Stories
Charlie Poole
Here's my shot at the stories/features for NUnitLite incorporating my own
vision as well as the ideas that you have sent in. It's rather long, so if
you want to comment on just one part, I suggest you include just the
excerpt. You may want to start a thread if it seems like a big discussion
item.
Note that these items are not prioritized in any way. I'd like to come up
with priorities 1 to 3 for them, where 1=Required early, 2=Need for the 1.0
release, 3=Could be postponed. After some discussion, I'll post a revised
list with those priorities and we can go another round. I figure it should
take no more than a week given the small size of this group.
WRITING TESTS
NUnitLite will recognize the constraint-based Assert syntax of NUnit in it's
entirety. All the same constraints are defined. The same syntax is used in
each.
There will be a small number of Asserts in the classic model of NUnit, but
only for the most commonly used cases. For example: Assert.Null,
Assert.True, Assert.False.
Tests are recognized using the TestFixture, Test, SetUp and TearDown
attributes just as in NUnit.
An ExpectedException attribute is provided with a subset of NUnit's
capabilities. Only the type of the exception and a handler may be specified.
Tests may also inherit from TestCase, in which case each method starting
with "test" is recognized as an individual test as NUnit 1.x.
Test suites are recognized by the presence of the static property Suite on a
class. This property must return a TestSuite populated with the tests to be
run as in NUnit 1.x.
Some or all of the following additional attributes may be provided:
Description, TestFixtureSetUp, TestFixtureTearDown, Ignore, Platform,
Category. [We should discuss these and separate them]
A compiler option will permit excluding all attributes and attribute
recognition from the build, for use on projects using the NUnit 1.x
approach.
Asserts, Attributes and Constraints will all use the NUnit.Framework
namespace for compatibility with NUnit.
RUNNING TESTS (INTERNAL)
Assemblies are examined and any qualifying classes are loaded as a flat list
of fixtures, each containing its own test methods. No namespace structure is
provided. Users may provide structure throught the use of the Suite
property.
Each test case is run until the first Assert failure, which causes an
exception to be thrown containing the failure message.
An option (compiler?) is available to report failures without use of
exceptions. [This is something I'm throwing out as an idea, since
first-chance exceptions can get very annoying. In order to do it, we would
need a technical solution of how to terminate the test case without throwing
an exception. In unmanaged code, I could play with the stack. Any ideas?]
An option allows reporting each /successful/ Assert.
TEST RUNNERS
NUnitLite incorporates a built-in text-based runner, which can send output
to the Console, Debug, a file or a TCP endpoint.
NUnitLite incorporates a built-in runner, which can creates xml output. The
output can be saved or sent to a TCP endpoint.
NUnitLite provides a progressive runner, which sends test progress to a TCP
endpoint while the test is being run. The runner may be incorporated in the
test assembly or - in the case of devices - deployed as a pre-installed test
agent.
A Gui-based runner for devices. [Clearly possible, but seems low in
importance. Nice for demos.]
[Some of the above features may be combined in a single runner]
USE AND MODIFICATION
NUnitLite tests should be compiled as an exe when run on devices and
(normally) as a dll when used to test plugins.
Programmers may compile NUnitLite separately and reference it from their
tests. It may be pre-installed on devices if desired.
Programmers may also combine NUnitLite with their test code as a single
assembly.
Programmers may tailor the build to remove unused functionality. Certain
compiler defines will be provided to assist in this.
Programmers may add functionality by modifying NUnitLite classes or
inheriting from them. Such work may be published under the terms of the
NUnitLite license - which requires using the same license for the modified
work.
Programmers may reuse the XML schemas provided with NUnitLite without
restriction. [How do people typically license schemas anyway?]
PLATFORM SUPPPORT
NUnitLite can run under Microsoft .NET V1.0 through 3.5 on all Windows
platforms beginning with Windows 95.
NUnitLite can run under the Mono 1.0 and 2.0 profiles on all supported
Platforms. [Currently, I test under Windows XP and Linux.]
NUnitLite can run under the .NET compact framework versions 1.0 and 2.0 on
all supported platforms.
NUnitLite can run under the .NET MicroFramework. [Possibly with restrictions
- I haven't gotten far with this yet.]
NUNIT SUPPORT
NUnit will run all NUnitLite tests identified by attributes without a
plugin.
We may provide a plugin to recognize other tests and to allow deploying and
running the tests on devices. [This is probably best done as part of the
NUnit 3.0 effort, since that version will be based on a complete
plugin-architecture.]
TOOL SUPPORT
NUnitLite will include batch deployment and execution tool for devices
NUnitLite will include a desktop gui tool for examining the xml output from
NUnitLite.
NUnitLite will include a NAnt task for running tests
NUnitLite will include an MsBuild task for running tests
NUnitLite may provide IDE addins for VS2005/2008, Sharpevelop, MonoDevelop
[Discuss in relation to NUnit support - i.e. NUnit may actually do this by
hosting an NUnitLite plugin.
NUnitLite may provide infrastructure TBD for testing addins to commonly used
applications like Visual Studio and Office.
EXCLUDED BY DESIGN
Supplementary Assert classes like StringAssert, FileAssert, etc.
Addins - the only extensibility is through use of normal mechanisms of
inheritance.
SetUpFixture.
Loading into separate AppDomains or processes.
Jeffry van de Vuurst
I'm just new to the group. I've been looking for a unit test framework
for mobile devices and want to include that in my automated build. So
as far as priorities I would say that NAnt and MSBuild tasks are high
on my list.
Thanks for the good work!
Jeffry
Vahan Hakobyan
Vahan Hakobyan
On Friday, August 31, 2007 at 10:13:46 PM UTC+4, Charlie Poole wrote:
Charlie Poole
NUnitLite went through a number of early releases and came out as
version 1.0 in 2013. Future development has now been merged with NUnit
and NUnit 3.0 (now in its alpha-5 release) comes with a new NUnitLite
assembly.
As described in the readme file, you use NUnitLite by creating an
executable application for your tests. In your case, that would be an
out-of-browser Silverlight application. You reference NUnitLite, which
runs the tests and creates a display of the result. The easiest way to
understand this is to look at the NUnitLite tests themselves.
Note that NUnitLite 3.0 is used slightly differently from NUnitLite
1.0. If you switch to 3.0, I'd suggest that you also switch from this
forum to the nunit-discuss list. I try to keep 3.0 discussions off
this list to avoid confusing anyone.
> You received this message because you are subscribed to the Google Groups
> "NUnitLite" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nunitlite+...@googlegroups.com.
> To post to this group, send email to nuni...@googlegroups.com.
> Visit this group at http://groups.google.com/group/nunitlite.
> For more options, visit https://groups.google.com/d/optout.
Vahan Hakobyan
You received this message because you are subscribed to a topic in the Google Groups "NUnitLite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nunitlite/286wZABFZ6w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nunitlite+...@googlegroups.com.
Charlie Poole
silverlight testing. We'll fix that
in the next release.
If you look at the NUnitLite tests themselves, in the file
App.xaml.cs, you will find this:
private void Application_Startup(object sender, StartupEventArgs e)
{
RootVisual = new NUnitLite.Runner.Silverlight.TestPage();
}
That's what you need to put in your own tests. In case you later
migrate to 3.0, it currently
works the same way, although that might change.
Charlie
On Tue, Feb 17, 2015 at 4:06 AM, Vahan Hakobyan
Vahan Hakobyan