New to java question about using my classes

OK, I'm fairly new to java, but making my way around pretty well these days. Enough to be REALLY dangerous!

My basic problem is making my classes usable in other classes. In short I built a class to use inside JUnit testing where I can choose which browser to run the automation in, and I need to get the user choice back from that class and then continue the test using one or all of the browsers that were selected. For extra credit I haven't added a timer to this class yet that automatically selects "All of the above" after three seconds, but I just got this part done after having been plagued by NullPointerExceptions for a while.

Thanks in advance for pointing me in the right direction to making this class more usable in other classses!!

Here is my code
import java.awt.GridBagConstraints; import java.awt.GridBagLayout; import java.awt.Insets; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import java.awt.event.WindowEvent; import javax.swing.JButton; import javax.swing.JComponent; import javax.swing.JFrame; import javax.swing.JLabel; import javax.swing.JOptionPane; import javax.swing.JPanel; import javax.swing.SwingUtilities; public class MyBlob { private static final int COLS = 1; private static final int ROWS = 5; private GridBagLayout gridBagLayout = new GridBagLayout(); /*int gridx, int gridy, int gridwidth, int gridheight, double weightx, * double weighty, int anchor, int fill, Insets insets, int ipadx, int ipady */ private static GridBagConstraints gridConstraints = new GridBagConstraints(1,1,ROWS,COLS,1.0,1.0, GridBagConstraints.CENTER,GridBagConstraints.BOTH, new Insets(0, 0, 0, 0),0,0); private JPanel mainPanel = new JPanel(); private JLabel lblNewLabel = new JLabel("Choose your browser"); private GridBagConstraints gbc_lblNewLabel = new GridBagConstraints(0,0,1,1,1.0,0.0, GridBagConstraints.CENTER,GridBagConstraints.BOTH, new Insets(5, 5, 5, 5),0,0); private JButton btnNewButton = new JButton("Chrome"); private GridBagConstraints gbc_btnNewButton = new GridBagConstraints(0,1,1,1,1.0,1.0, GridBagConstraints.CENTER,GridBagConstraints.BOTH, new Insets(0, 5, 5, 5),0,0); private JButton btnNewButton_1 = new JButton("FireFox"); private GridBagConstraints gbc_btnNewButton_1 = new GridBagConstraints(0,2,1,1,1.0,1.0, GridBagConstraints.CENTER,GridBagConstraints.BOTH, new Insets(0, 5, 5, 5),0,0); private JButton btnNewButton_2 = new JButton("Internet Explorer"); private GridBagConstraints gbc_btnNewButton_2 = new GridBagConstraints(0,3,1,1,1.0,1.0, GridBagConstraints.CENTER,GridBagConstraints.BOTH, new Insets(0, 5, 5, 5),0,0); private JButton btnNewButton_3 = new JButton("All of the above"); private GridBagConstraints gbc_btnNewButton_3 = new GridBagConstraints(0,5,1,1,1.0,1.0, GridBagConstraints.CENTER,GridBagConstraints.BOTH, new Insets(5, 5, 5, 5),0,0); public MyBlob(JFrame myFrame) { gridBagLayout.setConstraints(mainPanel, gridConstraints); mainPanel.setLayout(gridBagLayout); mainPanel.add(lblNewLabel, gbc_lblNewLabel); mainPanel.add(btnNewButton, gbc_btnNewButton); mainPanel.add(btnNewButton_1, gbc_btnNewButton_1); mainPanel.add(btnNewButton_2, gbc_btnNewButton_2); mainPanel.add(btnNewButton_3, gbc_btnNewButton_3); thehandler handler = new thehandler(myFrame); btnNewButton.addActionListener(handler); btnNewButton_1.addActionListener(handler); btnNewButton_2.addActionListener(handler); btnNewButton_3.addActionListener(handler); btnNewButton.getParent(); } public JComponent getMainComponent() { return mainPanel; } public static void createAndShowGui() { JFrame frame = new JFrame("Choose Browser"); MyBlob myBlob = new MyBlob(frame); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.getContentPane().add(myBlob.getMainComponent()); //frame.pack(); frame.setSize(250, 250); frame.setLocationByPlatform(true); frame.setVisible(true); } public static void main(String[] args) { SwingUtilities.invokeLater(new Runnable() { public void run() { createAndShowGui(); } }); } private class thehandler implements ActionListener { private JFrame thisFrame; private thehandler(JFrame windowFrame) { thisFrame = windowFrame; } public void actionPerformed(ActionEvent event){ if(event.getSource()==btnNewButton) { JOptionPane.showMessageDialog(null, "Chrome!"); thisFrame.dispatchEvent( new WindowEvent(thisFrame, WindowEvent.WINDOW_CLOSING));; } else if (event.getSource()==btnNewButton_1) { JOptionPane.showMessageDialog(null, "FireFox!"); thisFrame.dispatchEvent( new WindowEvent(thisFrame, WindowEvent.WINDOW_CLOSING));; } else if (event.getSource()==btnNewButton_2) { JOptionPane.showMessageDialog(null, "Internet Explorer!"); thisFrame.dispatchEvent( new WindowEvent(thisFrame, WindowEvent.WINDOW_CLOSING));; } else if (event.getSource()==btnNewButton_3) { JOptionPane.showMessageDialog(null, "All of the above!"); thisFrame.dispatchEvent( new WindowEvent(thisFrame, WindowEvent.WINDOW_CLOSING));; } } } }

Welcome to the Ranch!

Exactly what do you mean by "usable"? Usable in what way? Ideally, provide some sample code, even code that doesn't currently work, that illustrates just how you envision this class would be "used" by another class. For example,
// Animal.java: public class Animal { private String sound; public Animal(String sound) { this.sound = sound; } public void speak() { System.out.println(sound); } } // Zoo.java: public class Zoo { private List<Animal> wards = new ArrayList<>(); public void roleCall() { for (Animal animal : wards) { animal.speak(); } } public void add(Animal newWard) { wards.add(newWard); } }
In this code, the Zoo class uses the Animal class. Is this the kind of "use" you had in mind?

The JUnit test is a class. I want it to use the class above (MyBlob) to get user input, wait for the user to click an option or for the timer that I will develop to expire and the choice "All of the above" is made for the user at which point the JUnit class continues on it's marry way and is able to access the choice that the user made in MyBlob. If you run MyBlob you should be able to basically see what I'm trying to do. I'm trying to make it so MyBlob is usable in other classes ... I read that I can possibly create it as a returner class instead of having a static main, but I'm new, and tutorials have failed to explain this relationship between classes for me. Sure I see how sections of code can be broken out into classes just fine, but that leaves me with the question of how to get my input back into my parent class. Try to use my own example. I understand how classes relate to one another inside of the same file, but I'm breaking this out into it's own file and I need the user input back in the body of my JUnit class which is an automated browser test. I'd include all of this here, but that's a lot of code.

And thanks for the nice welcome, and quick response.

I am quite familiar with JUnit and its many capabilities. If you're interested, take a gander at our Testing forum and browse some of the more recent threads.

JUnit was not meant so much to be used for GUI testing (←that's a link, click on it) although with certain add-on libraries, it can also be used for that purpose. I personally don't like using JUnit to test functionality in the UI. I've found UI testing to be troublesome at best and tools that do it tend to be very finicky. My approach to avoiding UI testing is to push more logic to POJOs (Plain Old Java Objects). This is where stock JUnit testing excels.

The design principle involved here is called Separation of Concerns. The closest to this that I can think of in layman's terms is "Division of Labor". Essentially, you need to separate different kinds of responsibilities from each other. This involves organizing an application's pieces or components into different "layers" that each have a specific range of responsibilities. Common layers found in non-trivial applications include:

* Presentation or View - GUI/display/input from user

* Controller - "mediators" or "traffic cops" that direct the flow of information from one layer to another; also delegates to or invokes behaviors in components in different layers in response to events in other layers. For example, routing an incoming web request to the proper Business Service that will process the request.

* Persistence - saving data to and reading data from storage

* Model - usually consists of POJOs that represent the application's main logical entities and their behaviors

* Business / Services - usually consists of POJOs that represent work flows and transactions

There are other layers but the ones listed above are typical ones you'll find.

Anyway, that's a long way around the bush just to say that I wouldn't advise using JUnit to test this MyBlob class because there is so much GUI behavior in it. As a beginner, you might be better off by learning how to test functionality that has been separated from any kind of GUI. This way, your JUnit tests can run the way they were intended to run: very fast (less than 1 second for hundreds of tests) and with no interaction with the user (GIU input) or with external system resources (file system, database, web services, etc).

Welcome again

Have you ever come across Cai Horstmann's GBC class? It allows you to use GridBag without all those incomprehensible long lines.
There is a better description of GBC in Horstmann's book. Scroll down our books pages.

M. Kendall McIntosh wrote:My basic problem is making my classes usable in other classes. In short I built a class to use inside JUnit testing where I can choose which browser to run the automation in, and I need to get the user choice back from that class and then continue the test using one or all of the browsers that were selected. For extra credit I haven't added a timer to this class yet that automatically selects "All of the above" after three seconds...

I'd certainly echo Junilu's point about division of labour; particularly when it comes to display.

Java GUI code is notoriously finicky and verbose. Just look at the amount of code you've had to write to get the answer to a simple question.
And the problem is that, even when you've written it, it's only ONE way of getting the data. Others include:

A non-graphic console or terminal.

A Web page.

Arguments to your main() method.

A Database.

Files, Streams, or Pipes.

The main problem with GUIs is that they are so fiddly, so concerned with how you're going to get what you want done
- colours, buttons, icons, layout managers, and the like - that you often lose track of WHAT they're there to do.

Take your GUI above. It's actually a very basic task: You have a master list of browsers, and you want your user to select one or more from it,
which will be used somewhere else to run tests. Empirically, that suggests to me a function something like:public final Set<Browser> selectBrowsers(Set<Browser> masterList) { ... }All the rest is just window dressing.

Of course, in order to do it, you'll need a Browser class - or possibly even better, a Browser interface,
because then you could implement your "master list" as an enum.

HIH

Winston

The answer to Winston's question is that you should have an API which selects the browsers with methods like getBrowser(String name) and lots more. You should be able to use that API from the command line and pass a browser name to that method and get the browser you want. Get that working; once you have got that far, the GUI is simply a window to dress as Winston might say.

M. Kendall: One of my "crusades" as a developer is to help as many fellow developers as I can get educated on the proper application of unit testing techniques and making good use of test frameworks like JUnit. If you're interested, pop in sometime at the Testing forum where I like to hang out and we can walk through some scenarios for testing whatever it is you want to test.

Testing is often seen by developers as a "tedious chore", something that they'd just as well not do if they could keep coding instead. I have found that when done properly and with the right focus, testing is an essential and critical part of the process of producing good software and it's an activity that can actually make development fun and gratifying. When you have discovered this for yourself, as many professional developers have, I hope that you too will become "test-infected". Hope to see you in the Testing forum some time.

Good luck.

Campbell Ritchie wrote:Welcome again

Have you ever come across Cai Horstmann's GBC class? It allows you to use GridBag without all those incomprehensible long lines.
There is a better description of GBC in Horstmann's book. Scroll down our books pages.

this is helpful. I find updating the constraints to be a pain, and this addresses that issue quite nicely.

Junilu Lacar wrote:M. Kendall: One of my "crusades" as a developer is to help as many fellow developers as I can get educated on the proper application of unit testing techniques and making good use of test frameworks like JUnit. If you're interested, pop in sometime at the Testing forum where I like to hang out and we can walk through some scenarios for testing whatever it is you want to test.

Testing is often seen by developers as a "tedious chore", something that they'd just as well not do if they could keep coding instead. I have found that when done properly and with the right focus, testing is an essential and critical part of the process of producing good software and it's an activity that can actually make development fun and gratifying. When you have discovered this for yourself, as many professional developers have, I hope that you too will become "test-infected". Hope to see you in the Testing forum some time.

Good luck.

Sure, I'll pop in from time to time, but don't wait for me at the moment as I have a lot on my plate. "For me testing is a lifestyle" -- so said this Florida test engineer. I'm currently working heavily in the arena of test driven development and automated testing.

@Winston and @Campbell

Thanks for the input, and you've given me an idea that I am going to attempt. My idea is along the lines of creating a method that also runs the class just like static main does, and that method can have a return. Just need to figure out how that works with an event listener. I want my JUnit test to wait for user input, and not continue until it has it.

Anyway, thanks again for the help, ideas, and warm welcome.

M. Kendall McIntosh wrote:"For me testing is a lifestyle" -- so said this Florida test engineer. I'm currently working heavily in the arena of test driven development and automated testing.

Yes, that's right up my alley.

There are different ways of doing TDD and test automation though, some better than others but from what you've said so far, I'm hearing some alarms going off in the back of my head. I could be wrong but I like to think that I have a pretty good nose, and eyes and ears for those kinds of things. To be perfectly honest, the code that you posted is pretty jarring to my senses.

Lol

I learn very well from osmosis of having seasoned automation engineers around, so your help is greatly appreciated. If you have any examples then inbox them to me as I am at the first stages now and need guidance to avoid pitfalls later.

I have broken the long lines in the original post because they made the whole thread difficult to read. The presence of the comment on line 20 shows how awkward the constructor can be; Sun and Oracle suggest you should not use that constructor directly. I still think the Horstmann class would have made that code easier to write.

I feel I need to say a word about my choice of using the full constructor on the gridbag. I did that because I tried a number of ways to make things work the way I wanted and I iterated quickly through a few different options and I got tired of moving lots of lines of code around, and that simplified things for me. If there were several options I would have explored them, but that eliminated a lot of lines of code at once, so I could focus on what I was trying to achieve. I would do things differently if I was attempting to win an award for beautiful code, but I needed to simplify to complete the task quickly, that worked for me, and I didn't go back to change it, and I ask for forgiveness for what I knew to be dirty code. I didn't mean for everyone to focus on that particular point when to me it really got a lot of things out of the way and tucked up nice and neat. I used the comment to be able to reference what the different parts were... obviously. I promise to make better attempts to make code more readable, and I'll consider the width requirements of webpages that will likely be viewed on phones in the future.

M. Kendall McIntosh wrote:I would do things differently if I was attempting to win an award for beautiful code, but I needed to simplify to complete the task quickly, that worked for me, and I didn't go back to change it, and I ask for forgiveness for what I knew to be dirty code.

As long as there was no malice intended on your part, there's no need to ask forgiveness here. Nobody is trying to make you feel guilty, regardless of how any of our well-meant but honest remarks may come across.

I do find what you said there a bit contradictory to your earlier claim that you are "...working heavily in the arena of test driven development and automated testing." TDD usually drives you to write code that could give lots of other code a run for their money in a beauty contest. Also, as Uncle Bob Martin likes to say, "the only way to go fast, is to go well." You'll eventually end up slowing yourself down if you keep choosing to do the expeditious thing and leave your dirty code laying around all over the place.

M. Kendall McIntosh wrote:...but I needed to simplify to complete the task quickly, that worked for me...

Have you heard the old saying: "More haste; less speed"? Well it's probably nowhere truer than in programming - and it's what my signature line is all about. It can be very difficult when you're working to a tight schedule to give yourself time to think; but it's incredibly important.

Good programs don't just write themselves, and they're almost NEVER achieved by starting to code straight away. You have to give your brain enough time to digest the elements of the problem (which are almost always far larger and more abstract than individual lines of code) and arrange them in a way that YOU understand. After that, the act of coding simply becomes one of translating what you already know into Java.

Junilu's post about "layers" is a really good one to try and take in.
You might also be interested in the StopCoding (←click→) and WhatNotHow pages.

and I didn't go back to change it, and I ask for forgiveness for what I knew to be dirty code.

No need to apologise; we've ALL been there.

I'm a little worried that we've drifted into an explanation of the best way to implement GridBagLayout though, rather than sticking with the business of separation (or "layering"), because I've seen nothing so far that leads me to believe you actually need a GUI at all (yet).

And that's the problem with GUIs: they're so damn fiddly and verbose that you spend all your time getting them to work, rather than concentrating on the problem at hand.
Don't get me wrong: they are important, but in many cases you can plug them in at the end; after you have a working model that operates with a much simpler interface (eg, keyboard and terminal).

And the great thing about doing things that way is that you tailor your GUI to your model (or application), NOT the other way around - or even worse: mixing the two together.

HIH

Winston

Winston Gutkowski wrote:"More haste; less speed"?

That's a great complement to "The only way to go fast, is to go well." I'm going to start tacking on that bit in future references, thank you. And thanks for the nod about the application layers.