I am a fan of JUnit ! I have been working with it for some time now
and I have come up with an extension of it for testing server-side
java code that is called either by Servlets or JSP. I thought that
you could find this of interest ...
Please have a loot at it at http://sourceforge.net/projects/j2eeunit/
and tell me what you think
Thanks.
Vincent.
Hi Vincent,
I'm the only person subscribed to this list other than you. :)
I haven't announced it yet, but will soon. How did you find it
so fast? I just created it last night.
Erik
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@...]
> Sent: Monday, November 06, 2000 8:11 AM
> To: junit@egroups.com
> Subject: [junit] J2EEUnit
>
>
> I am a fan of JUnit ! I have been working with it for some time now
> and I have come up with an extension of it for testing server-side
> java code that is called either by Servlets or JSP. I thought that
> you could find this of interest ...
>
> Please have a loot at it at http://sourceforge.net/projects/j2eeunit/
> and tell me what you think
>
> Thanks.
> Vincent.
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@egroups.com
>
>
Hi Vincent!
I am a big fan of JUnit also.
I too was once working on a framework much like the one you posted
j2eeunit.
Them someone showed me HttpUnit (which did was I was already doing but
in a more fully featured way).
I have not had a chance to go through all your docs yet but you can
check out HttpUnit at:
http://httpunit.sourceforge.net/
I would very much like to hear your comments on features j2eeunit
provides vs HttpUnit.
Have a good weekend.
Jonathan
> Please have a loot at it at
http://sourceforge.net/projects/j2eeunit/
> and tell me what you think
>
> Thanks.
> Vincent.
Hi Jonathan,
HttpUnit and J2EEUnit are doing different things :
- HttpUnit tests the result of calling a JSP or Servlet, i.e. it gets
the HTML/XML/WML/... returned and let you verify HTTP headers,
cookies, ... + some regexps to check the returned content
- J2EEUnit (in its initial version) does unit testing of server-side
java code, i.e. it executes on the server and let you unit test
methods of your java classes called by the JSPs and Servlets.
Now, I intend to improve J2EEUnit in the following 2 fields :
- Let it do what HttpUnit does (actually Russell, who did the
HttpUnit framework, haas contacted me to check what synergy we could
have to merge the two),
- Add EJB unit testing
Thanks.
Vincent.
He, he !
It seems it existed before you created it last night !, because I
subscribed to it a week ago ... :)
--- In junit@egroups.com, "Erik Meade" <emeade@g...> wrote:
> Hi Vincent,
>
> I'm the only person subscribed to this list other than you. :)
> I haven't announced it yet, but will soon. How did you find it
> so fast? I just created it last night.
>
> Erik
>
Vincent Massol wrote:
>
> - J2EEUnit (in its initial version) does unit testing of server-side
> java code, i.e. it executes on the server and let you unit test
> methods of your java classes called by the JSPs and Servlets.
>
How is this different from simply using JUnit? I can test java classes
with it too.
--
David Corbin
Mach Turtle Technologies, Inc.
http://www.machturtle.com
dcorbin@...
Yes, you're right but some of these java classes need to have access
to valid HttpServletRequest, HttpServleetResponse and HttpSession
objects. One other workaround solution would be to put a facade in
front of all these objects for your classes. However, this can be
difficult to do when you need to manipulate intensively these objects
in your classes. Moreover, even if you use the facade, you may still
need to test your servlets ...
Thanks.
Vincent.
--- In junit@egroups.com, David Corbin <dcorbin@m...> wrote:
> Vincent Massol wrote:
> >
> > - J2EEUnit (in its initial version) does unit testing of server-
side
> > java code, i.e. it executes on the server and let you unit test
> > methods of your java classes called by the JSPs and Servlets.
> >
>
> How is this different from simply using JUnit? I can test java
classes
> with it too.
> --
> David Corbin
> Mach Turtle Technologies, Inc.
> http://www.machturtle.com
> dcorbin@m...
--- In junit@egroups.com, "Vincent Massol" <vmassol@o...> wrote:
> - Add EJB unit testing
>
Thats great to hear. I have done a considerable amount of EJB tests
with JUnit and may be able to contribute.
Cheers
Jonathan
OK. I just D/Led the V3.2 JUnit and I made a simple application
under JBuilder 4.0 (which I'm also trying to come up to speed on)
that has a simple unit test case (shown below). I've been looking
at the cook book HTML pages, but I don't see how I hook this into
the GUI TestRunner. I made a test case and made a suite() function
as suggested, but am now stuck on how to tie in one of the GUI
TestRunners. There is an example for the batch version of the
TestRunner, but I don't see anything on a GUI version.
Can anyone provide some pointers?
Can I make use of Reflection to have the TestRunner find all my
test cases?
Thanks!
PCM
----- CODE BEGIN -----
package summarizer;
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
public class TestSummarizer extends TestCase {
public TestSummarizer(String name) {
super(name);
}
public void testDummy() {
fail("Not implemented yet");
}
public void setUp() {
summarizer = new Summarizer();
}
public void tearDown() {
}
public static Test suite() {
TestSuite suite= new TestSuite();
suite.addTest(new TestSummarizer("testDummy"));
return suite;
}
private Summarizer summarizer;
}
----- CODE END -----
P.S. I have the src.zip and junit.jar files specified in the
Project Properties (for sources and required libraries).
on 11/14/00 7:58 AM, Paul Michali at pcm@... wrote:
> OK. I just D/Led the V3.2 JUnit and I made a simple application
> under JBuilder 4.0 (which I'm also trying to come up to speed on)
> that has a simple unit test case (shown below). I've been looking
> at the cook book HTML pages, but I don't see how I hook this into
> the GUI TestRunner. I made a test case and made a suite() function
> as suggested, but am now stuck on how to tie in one of the GUI
> TestRunners. There is an example for the batch version of the
> TestRunner, but I don't see anything on a GUI version.
>
> Can anyone provide some pointers?
If you run the GUI test runner (junit.ui.LoadingTestRunner, for example)
with your test cases somewhere on the classpath, you can run them by typing
the name of the test case into the edit box in the UI and hitting "run". If
the test case has a static suite() method, it'll run that; otherwise, it
will use reflection to find all of the "public void testXXX" methods in your
class.
The LoadingTestRunner runner will reload your test classes each time you hit
"run", so you don't need to start it over all the time. (It seems to have a
few quirks with native code, at least in my experience, though, and doesn't
yet load from jars and zips, although I believe that is coming in 3.3.) A
non-loading TestRunner class is also available.
> Can I make use of Reflection to have the TestRunner find all my
> test cases?
For an individual TestCase class, this works great in JUnit 3.2. The runner
will find all of the methods in the test case with a signature like "public
void testXXX()" if there is no other suite() method -- this means that you
don't have to build suite() methods for individual classes by hand, at least
most of the time. If you're building AllTests suites (which I think are
mentioned somewhere in the documentation) or the like, you can use something
like
public static Test suite()
{
TestSuite suite = new TestSuite();
suite.add(new TestSuite(YourTestCase.class));
suite.add(new TestSuite(AnotherTestCase.class));
return suite;
}
to get the same effect with a composite suite.
As far as finding all the test case classes available in the system, I'm not
aware of anything that does it. I think that one could do it by examining
the classpath (available via System.getProperty()) for .class files and
using reflection to determine whether they were TestCases, but I haven't yet
tried it. Anybody have anything that does this?
Hope this helps,
Ben Schroeder
schroeder@...
Benjamin Schroeder wrote:
> on 11/14/00 7:58 AM, Paul Michali at pcm@... wrote:
>
> > OK. I just D/Led the V3.2 JUnit and I made a simple application
> > under JBuilder 4.0 (which I'm also trying to come up to speed on)
> > that has a simple unit test case (shown below). I've been looking
> > at the cook book HTML pages, but I don't see how I hook this into
> > the GUI TestRunner.
>
> If you run the GUI test runner (junit.ui.LoadingTestRunner, for example)
> with your test cases somewhere on the classpath, you can run them by typing
> the name of the test case into the edit box in the UI and hitting "run". If
> the test case has a static suite() method, it'll run that; otherwise, it
> will use reflection to find all of the "public void testXXX" methods in your
> class.
I guess I'm a bit dense, but I still can't get this to work. SOme of it is my
inexperience with Java, jar files, and JBuilder.
Here's what I've tried...
Inside JBuilder4, I created the (previously posted) TestSummarizer class.
Under the project properties, I told JBuilder that the main class is
junit.swingui.TestRunner. I built everything and tried to run under the
debugger with my test class (TestSummarizer), which has one test method
called testDummy(), specified as the sole command line argument.
The program comes up, and tells me that the class (TestSummarizer) is
not found.
Next, I used Jbuilder4's archive wizard and built a JAR file. From the
command line, I typed "java -jar TestSummarizer.jar". The program
runs and when I enter 'TestSummarizer" and press the "Run" button, it
does not find the class either. I tried adding the full path to the directory
where the TestSummarizer.class file lives to my CLASSPATH
environment variable, but I get the same results.
I'll try doing the same thing using one of the test classes from JUnit.
Any suggestions as to what I'm doing wrong? This sounds like it
should be easy...
PCM
on 11/14/00 12:50 PM, Paul Michali at pcm@... wrote:
> I'll try doing the same thing using one of the test classes from JUnit.
>
> Any suggestions as to what I'm doing wrong? This sounds like it
> should be easy...
I had a look back at your source, and noticed that the source was in a
package. Are you just using "TestSummarizer" as the class name? The JUnit
GUI requires fully-qualified class names, e.g., "summarizer.TestSummarizer".
The classpath should then point one level up from the "summarizer" package
directory. (Should be fine as-is from JBuilder, though, I think; I've not
used JBuilder, though, so I'm not sure.)
If that's not it, I'm pretty confused too! Have you tried using the
-classpath command line option instead of the environment variable?
---
Ben Schroeder
schroeder@...
Benjamin Schroeder wrote:
> I had a look back at your source, and noticed that the source was in a
> package. Are you just using "TestSummarizer" as the class name? The JUnit
> GUI requires fully-qualified class names, e.g., "summarizer.TestSummarizer".
> The classpath should then point one level up from the "summarizer" package
> directory. (Should be fine as-is from JBuilder, though, I think; I've not
> used JBuilder, though, so I'm not sure.)
Yes! That was the problem. When I created the class, using the JBuilder's
wizard, I had it create a package. When I ran from the IDE and specified
summarizer.TestSummarizer, it worked! (I also made a suite() method)
> If that's not it, I'm pretty confused too! Have you tried using the
> -classpath command line option instead of the environment variable?
I was also able to get it to work from the command line by adding the
path to the class with the "-cp" arg.
The package was the clincher. Thanks alot!
PCM (Paul Michali)
Voice Gateway Solutions Business Unit (VGSBU)
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Phone : (800) 572-6771 x 45817 (978) 244-5817 [direct]
Paging: (800) 365-4578 [voice] pcm@... [email page]
on 11/14/00 2:49 PM, Paul Michali at pcm@... wrote:
> I was also able to get it to work from the command line by adding the
> path to the class with the "-cp" arg.
>
> The package was the clincher. Thanks alot!
No problem -- glad to hear you got it working!
---
Ben Schroeder
schroeder@...
Hi,
currently I run the SwingUI issuing
java -classpath <path>/junit.jar:<myclasses> junit.swingui.TestRunner
TestPackage
assuming you have a class called TestPackage containing a method suite()
in the
toplevel package of your application.
> As far as finding all the test case classes available in the system, I'm not
> aware of anything that does it. I think that one could do it by examining
> the classpath (available via System.getProperty()) for .class files and
> using reflection to determine whether they were TestCases, but I haven't yet
> tried it. Anybody have anything that does this?
I will support that in some of the next JUnitX versions although there
is a
drawback. If somebody manually removes a test from a suite() method
because
it is broken and no longer maintained for some reason, it would be
collected
by an automated search.
Using a special marker interface might be a rough solution, but there is
more
to it than just working around Java´s restrictions in traversing the
tree
of avail classes.
Regards,
Andreas.
on 11/14/00 4:21 PM, Andreas Heilwagen at andreas.heilwagen@... wrote:
>> As far as finding all the test case classes available in the system, I'm not
>> aware of anything that does it. I think that one could do it by examining
>> the classpath (available via System.getProperty()) for .class files and
>> using reflection to determine whether they were TestCases, but I haven't yet
>> tried it. Anybody have anything that does this?
>
> I will support that in some of the next JUnitX versions although there
> is a
> drawback. If somebody manually removes a test from a suite() method
> because
> it is broken and no longer maintained for some reason, it would be
> collected
> by an automated search.
> Using a special marker interface might be a rough solution, but there is
> more
> to it than just working around Java´s restrictions in traversing the
> tree
> of avail classes.
I suppose that's true. On the other hand, traversal might be a nice first
cut.
Each package could have a "restrictions.txt" file or something similar that
listed cases not to run. Another idea might be to enhance the TestRunner to
allow you to disable certain found tests, especially if not running a given
test were a temporary thing. In my development, this would probably be OK,
since I might remove or otherwise disable more permanently a test that I
wasn't maintaining at the moment.
If the test finder looked for a suite() method in each TestCase class before
using its methods via reflection, one could disable an entire TestCase by
simply returning an empty TestSuite from that method. (I'm not sure if the
"new TestSuite(SomeTest.class)" already looks for suite methods or not.)
Another issue might be use of native code in some tests: our team has
"AllTests" and "ReallyAllTests" to exclude some classes that we haven't been
able to make work well under the loading runner. (For the curious: we get a
security exception of some kind. We might be able to work around this,
especially with Java 2, but haven't yet with 1.1.)
I might play around with some of this using JUnit 3.2 if possible, but I'm
not sure that I'll find time.
By the way, what are some of the forces that led you to start JUnitX? I
haven't had a chance to really play with it, but might -- it looks like it
could have some nice stuff. (I'm not sure whether I'd use the major
functionality of access to restricted classes and members or not, though.)
Does it work with JDK 1.1?
---
Ben Schroeder
schroeder@...
Reasons why I use JUnit
Because I want to refactor aggressively.
Because I want to find bugs quickly.
Gives me greater confidence in my code.
I am entitled to produce quality code.
Leads me to deeper understanding more quickly.
Keeps me focused.
Always makes me feel like I am moving forward.
When I get stuck I know exactly where I am stuck.
I always have real live up to date documentation showing me how my
code works.
My code is very testable.
These are a few of my favorite things...
Jonathan
Just to let you know -- I can't use JUnitX because it is too reliant on Java2. On Windows, I'm using IBM JRE, which is not Java2.
On the Macintosh, you should know that MacOS 7/8/9 will _never_ support Java2. This is mostly for technical reasons [Apple having difficulty in porting Sun's sources], but it also serves to motivate people to upgrade to MacOS X, which will not be shipping in a final form until next year.
Hi Piero,
I'm still stuck too. I am reduced to running up TestRunner from the method
and then running the tests. They work when you set up the classpath on
TestRunner itself.
I still cannot figure how to get it running from the tool menu though :-(
Tom
Piero Campanelli wrote:
> Hi,
>
> have tried to use JUnit 3.2 in VaJAVA 3.5 as an IDE tool ?
> I am unable to figure out how to do it ....have you any help ?
>
> Tnx
>
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@egroups.com
>> have tried to use JUnit 3.2 in VaJAVA 3.5 as an IDE tool ?
>> I am unable to figure out how to do it ....have you any help ?
Tim Mackinnon has done all the hard work for us and uploaded a package called BigBenTools to the xp developers website (see attached URL) this integrates well with VisualAge forJava and is accompanied by a good set of installation instructions. Please forgive me if you are already aware of this.
Hi,
very nice work this tool !
It doesn't solve cleanly problem of JUnit and VaJava 3.5
but it patchs it using start() method !! Now I can use
JUnit in Va !! Thank you
Piero
-----Original Message-----
From: Anthony Dickinson [mailto:adickinson@...]
Sent: giovedì 16 novembre 2000 9.52
To: 'junit@egroups.com'
Subject: [junit] FW: JUnit and VaJava 3.5
Piero Campanelli wrote:
>> have tried to use JUnit 3.2 in VaJAVA 3.5 as an IDE tool ?
>> I am unable to figure out how to do it ....have you any help ?
Tim Mackinnon has done all the hard work for us and uploaded a package
called BigBenTools to the xp developers website (see attached URL) this
integrates well with VisualAge forJava and is accompanied by a good set of
installation instructions. Please forgive me if you are already aware of
this.
http://www.xpdeveloper.com/cgi-bin/wiki.cgi?BigBenTools
regards
Anthony
Anthony G Dickinson
Senior Developer - myOyster plc.
Tel.work : +44 (0) 1753 240029
Tel.work.mob : +44 (0) 7765 898226
Tel.home.mob : +44 (0) 7712 777239
mailto: adickinson@...
eGroups Sponsor
To unsubscribe from this group, send an email to:
junit-unsubscribe@egroups.com
Benjamin Schroeder wrote:
>
> By the way, what are some of the forces that led you to start JUnitX? I
> haven't had a chance to really play with it, but might -- it looks like it
> could have some nice stuff. (I'm not sure whether I'd use the major
> functionality of access to restricted classes and members or not, though.)
> Does it work with JDK 1.1?
I started JUnitX after reading the Refactoring-book of Martin Fowler.
During my vacation I had real fun refactoring JUnit and afterwards I
have been curious how it would be possible to access private methods,
classes and attributes across packages. So I had to extend JUnit in
many aspects. Also the Swing GUI required more clicks than I liked to
access the tree of tests. So I reworked the Swing and Text UIs.
Now it is a challenge to submit the changes to JUnit. I hope that JUnit
soon gives me the opportunity to give my best changes to it after
having somebody reviewing them. So I am sad that it is a branch
development. But I will definitely support _all_ JUnit features in
the JUnitX versions until everything has been merged sufficiently.
I never tested the stuff with JDK 1.1. But it should be possible to
backport the stuff. Are you interested in doing that? Than you might
want to join extreme-java@egroups.com, the JUnitX and XPTest mailinglist
I set up for developers.
Concerning testing private code, it depends on your preferences.
Generally
it would be better not to access private code since there is a reason
for beeing private. But sometimes you might want to ensure that
complex algorithms work corrently and there it could be helpful to
access the inner state of a class. See it as a kind of last resort to
be sure that a test case tests the right stuff completely. It should
not become the general way of testing your production classes.
Regards,
Andreas.
Ok,
I understand that a lot of people will be interested in using JDK 1.x.
The appropriate action point will be added to my TODO list. Thanks
for the feedback.
Regards,
Andreas.
> Keith Ray wrote:
>
> Just to let you know -- I can't use JUnitX because it is too reliant
> on Java2. On Windows, I'm using IBM JRE, which is not Java2.
>
> On the Macintosh, you should know that MacOS 7/8/9 will _never_
> support Java2. This is mostly for technical reasons [Apple having
> difficulty in porting Sun's sources], but it also serves to motivate
> people to upgrade to MacOS X, which will not be shipping in a final
> form until next year.
Hi Jonathan,
With the current J22EUnit, it is already possible to unit test EJBs. In your
testXXX() method just do a lookup on the home, create the bean and call it's
remote methods. I am still wondering what I could add to make EJB testing
attractive and useful :
- I could first hide calling an EJB remote method by automatically setting
JNDI, doing the lookup, create the bean instance and calling the remote
method,
- What could I do more ?
Thanks and please feel free to contribute.
Vincent
----- Original Message -----
From: "Jonathan Rasmusson" <jr@...>
To: <junit@egroups.com>
Sent: Tuesday, November 14, 2000 4:57 AM
Subject: [junit] Re: J2EEUnit
> --- In junit@egroups.com, "Vincent Massol" <vmassol@o...> wrote:
>
> > - Add EJB unit testing
> >
>
> Thats great to hear. I have done a considerable amount of EJB tests
> with JUnit and may be able to contribute.
>
> Cheers
>
> Jonathan
>
>
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@egroups.com
>
>
>
>
>
>
> Concerning testing private code, it depends on your preferences.
> Generally
> it would be better not to access private code since there is a
reason
> for beeing private. But sometimes you might want to ensure that
> complex algorithms work corrently and there it could be helpful to
> access the inner state of a class. See it as a kind of last resort
to
> be sure that a test case tests the right stuff completely. It should
> not become the general way of testing your production classes.
>
> Regards,
>
> Andreas.
My experiences have been the same as Andreas. I tend to favour
protected over private in my objects then if I place the test in the
same package as my class I can test practically everything.
If I do want to place my tests in a separate test directory, I can
make a child class of my parent class (extends) and then proxy calls
up to the parent via the child and test in the tests directory.
The extra work required is creating the child class and calling super
up to the parent whenever a test is called on the child.
Jonathan
Hi,
We apply the following strategies to make our EJB's *fully* testable.
1. EJB's are thin. They are really really thin. The EJB is in fact an
interface into a "Box". Each Box owns some tables in the database. Each Box
has its private DB package (we do bean-managed), its own EJB (that acts ass
an interface into the box), and one or more so-called Business Logic
packages. These BL packages do all the work. The BL code is Unit Tested in a
very detailed way. The only thing the EJBs do is communicate with other
EJB's and then call the BL code with the retrieved data.
2. We also test the EJBs, but only very roughly. Every remote method is
called, just to see that they work. The details are not tested here, because
they are covered in the BL Unit Tests.
3. To be able to work quickly (hot deployment with underlying packages is
not really possible) we use bipolar EJB creators iso the regular EJB Home
for the session EJBs. That is a factory that returns the EJB in the normal
way (created by the EJB Home) *or* as a simple local object, depending on a
property that can be specified in a config file. While developing, we
usually run the tests on the local session EJBs. Very nice for debugging
too.
4. Only when development of the EJB function is finished, we run the tests
on the remote EJB.
bye,
vp
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@...]
> Sent: donderdag 16 november 2000 22:23
> To: junit@egroups.com
> Subject: Re: [junit] Re: J2EEUnit
>
>
> Hi Jonathan,
>
> With the current J22EUnit, it is already possible to unit test
> EJBs. In your
> testXXX() method just do a lookup on the home, create the bean
> and call it's
> remote methods. I am still wondering what I could add to make EJB testing
> attractive and useful :
> - I could first hide calling an EJB remote method by automatically setting
> JNDI, doing the lookup, create the bean instance and calling the remote
> method,
> - What could I do more ?
>
> Thanks and please feel free to contribute.
> Vincent
>
> -----Original Message-----
> From: Andreas Heilwagen [mailto:andreas.heilwagen@...]
> Sent: Thursday, November 16, 2000 9:16 AM
> To: junit@egroups.com
> Subject: Re: [junit] Automatic test finding / JUnitX (was: How to hook
> test cases into GUI testrunner)
>
>
> Benjamin Schroeder wrote:
> >
> > By the way, what are some of the forces that led you to start JUnitX? I
> > haven't had a chance to really play with it, but might -- it
> looks like it
> > could have some nice stuff. (I'm not sure whether I'd use the major
> > functionality of access to restricted classes and members or
> not, though.)
> > Does it work with JDK 1.1?
>
> I started JUnitX after reading the Refactoring-book of Martin Fowler.
> During my vacation I had real fun refactoring JUnit and afterwards I
> have been curious how it would be possible to access private methods,
> classes and attributes across packages. So I had to extend JUnit in
> many aspects. Also the Swing GUI required more clicks than I liked to
> access the tree of tests. So I reworked the Swing and Text UIs.
>
> Now it is a challenge to submit the changes to JUnit. I hope that JUnit
> soon gives me the opportunity to give my best changes to it after
> having somebody reviewing them. So I am sad that it is a branch
> development. But I will definitely support _all_ JUnit features in
> the JUnitX versions until everything has been merged sufficiently.
>
> Regards,
>
> Andreas.
JUnit should have an open source host soon.
--
Erik Meade emeade@...
Senior Consultant Object Mentor, Inc.
http://www.junit.org
> 1. EJB's are thin. They are really really thin. The EJB is in fact an
> interface into a "Box". Each Box owns some tables in the
> database. Each Box
> has its private DB package (we do bean-managed), its own EJB
> (that acts ass
> an interface into the box), and one or more so-called Business Logic
> packages. These BL packages do all the work. The BL code is
> Unit Tested in a
> very detailed way. The only thing the EJBs do is communicate
> with other
> EJB's and then call the BL code with the retrieved data.
So you don't implement business logic as session beans??? Sounds
weird...
ciao, Ilja
Send Email
