• Post Reply Bookmark Topic Watch Topic
  • New Topic

Problem with Head First Java  RSS feed

 
Craig E. Lewis
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey every body I am currently having a problem with understanding Head First Java. Particularly the test code. My question is do you have to put the test code in the same file as the the real code? Basically what is the test code and where do you use it? Thanks in advance.
 
Bill Johnston
Ranch Hand
Posts: 201
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Craig E. Lewis wrote:Hey every body I am currently having a problem with understanding Head First Java. Particularly the test code. My question is do you have to put the test code in the same file as the the real code? Basically what is the test code and where do you use it? Thanks in advance.


Does this link help?

http://www.headfirstlabs.com/books/hfjava/
 
Craig E. Lewis
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm Sorry but no.
 
dennis deems
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Test code should be in a separate file. Tests are generally kept in a separate source folder, but while you are learning it's fine to keep them in the same package with the classes they test.

A test is just a small program that typically instantiates a class and verifies its behavior. The idea is to make the class do everything it can do - call every public method, force every execution path to occur - and make sure that what you expect to happen is what actually happens.

For example: when we flip a light switch, we expect the light to come on or go off depending on what state it's currently in. A LightSwitch class might have a flip() method that causes this behavior. And we would test that with a LightSwitchTest class that instantiates the switch and calls the flip() method. Then we would check the state of the light and confirm that it is ON.

Tests are executed whenever we want to verify that our program works the way it's supposed to. Most projects will be tested periodically during development and while in production, typically once a night but it could happen more often depending on a number of things that aren't really important to discuss right now. If you happen to be fixing a bug in a program, you will probably be running its tests quite a lot as you modify the code.
 
Bill Johnston
Ranch Hand
Posts: 201
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Craig E. Lewis wrote:I'm Sorry but no.


At the top of the page there is a link to forums specific to each book. Perhaps that might be helpful.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dennis Deems wrote:Test code should be in a separate file. Tests are generally kept in a separate source folder, but while you are learning it's fine to keep them in the same package with the classes they test.

A test is just a small program that typically instantiates a class and verifies its behavior. The idea is to make the class do everything it can do - call every public method, force every execution path to occur - and make sure that what you expect to happen is what actually happens.


There's also a school of thought (to which I happen to subscribe) that says that you put your test classes in a different directory from your "real" classes, but in the same package, so that you can test package-private methods more easily, and also for simple ease of organization--you have x.y.z.FooTest which tests x.y.z.Foo.

 
dennis deems
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:
Dennis Deems wrote:Test code should be in a separate file. Tests are generally kept in a separate source folder, but while you are learning it's fine to keep them in the same package with the classes they test.

A test is just a small program that typically instantiates a class and verifies its behavior. The idea is to make the class do everything it can do - call every public method, force every execution path to occur - and make sure that what you expect to happen is what actually happens.


There's also a school of thought (to which I happen to subscribe) that says that you put your test classes in a different directory from your "real" classes, but in the same package, so that you can test package-private methods more easily, and also for simple ease of organization--you have x.y.z.FooTest which tests x.y.z.Foo.


Agreed.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!