Programming Myself.. Ambati Sreedhar: Testing

UX

Tue, 01 Jul 2008 14:49:24 GMT

In these 4 yrs of my experience in software industry I learned so many things related to technical and

nontechnical things.
Project Managers are paid more than developers.
People who are having good communication skills reaches to the top levels faster.
Why I mentioned the above .. I have reason ...
Why some projects fail even though they are having good functionality comparing with their competitor

products ..? Reasons may be poor marketing, managing skills . Leave these organisational issues.They

fail because of lack of User Experience capabilities.
When I joined as a fresher I have very bad idea on UX things and people who are stressing on that.
But it was changed now.
It plays a vital role in the success of the projects.

Vic's "Building Great UX With .Net"
I know before the session itself that it is not a technical session.
But I know the importance of UX.
And he told before starting to the session that it is not going to be a technical session.
I liked his frankness.
Among all the keynotes delivered in Developer Summit the best keynote was from "Jesse James Garrett".His

speech is not new technical trends but about the importance of user experience and innovation. Everybody

appreciated his session.
Now world understood the importance of UX in every aspect.

Vic started his session with a slide which has a question like "Is UX=UI? Or is just another buzzword.."
He gave answer to it and told the importance of it.
User Experience is about everything like adaptability,extensibility,scalability,reliability,performance.
He explained the different roles played by different persons in the industry like Information

Architect,Interaction Designer,Usability Engineer,Visual Designer,software architect and how these

people fit in User/Human-Centered design.

If developer has taken little care about UX while coding it will show great impact on the user

acceptance and it differentiates in the market place.
One slide which helps organisations where to invest and how much to invest...
That graph shows user-adoption vs purpose.
Choose agile fora UX-friendly process like Test Driven Development,Behaviour Driven Development,Domain

Driven Design.
Testing UX can be done using heavyweight ,lightweight ,tunnel vision.
He discussed about UX patterns. Can find at infragistics.com/ux.
Refactoring also plays a vital role in UX.
Net gives you so many technologies but not UX expertise and design,Human - Centered Thinking.
So you have to incorporate those qualities.

Some references:
www.welie.com
www.lukew.com/ff
www.uxmatters.com
For better UX we have to change our approach "Design from the outside in!"

Vic can be reached at vic@infragistics.com
Overall it gave insight about the importance of UX and its a good session.

Presentation is available at:
http://bdotnet.in/files/folders/ppts/entry2000.aspx

SSRS : File Share Subscription

Thu, 12 Jun 2008 11:34:20 GMT

In SSRS we have File and Email and also custom

http://msdn.microsoft.com/en-us/library/ms157386.aspx

To create a file share subscription
In Report Manager, on the Contents page, navigate to the report you want to subscribe to. Click the report to open it.

Click the Subscriptions tab, and then click New Subscription.

For the method of delivery, select Report Server File Share from the Delivered by list box.

Type a file name for this subscription in the File name text box.

Ensure that Add a file extension when the file is created is selected. This causes the report to be saved with a three-character file extension. The file extension is determined by the rendering format you select.

In the Path text box, type a Universal Naming Convention (UNC) path to an existing folder where you want to deliver the reports (for example, \\<servername>\<myreports>). Include double backslash characters at the beginning of the path. Do not specify a trailing backslash.

Select a render format for file delivery. Choose a format that corresponds to the desktop application that will be used to open the report. Avoid formats that do not render a report in a single stream or that introduce interactivity that cannot be supported in a static file (that is, HTML 3.2, HTML 4.0, or HTML with Office Web Components).

In the User name and Password text boxes, specify the credentials required to access the file share, using the format <domain>\<user name> for the user name. It means your system login name and password

Specify overwrite options. If you click Do not overwrite the file if a previous version exists, the delivery will not occur if an existing file is detected. If you click AutoIncrement, the report server appends a number to the file name to distinguish it from existing files of the same name.

Specify subscription delivery options as follows:

To specify a delivery schedule, click When the scheduled report run is complete and click the Select Schedule button. A schedule page opens.

For parameterized reports, specify parameters to use for the report for this subscription. The parameters can be different from those used to run the report on demand or in other scheduled operations.

http://www.sqlmonster.com/Uwe/Forum.aspx/sql-server-reporting/21199/Cache-rsInvalidDataSourceCredentialSetting

Error-Message:
"The current action cannot be completed because the user data source
credentials that are required to execute this report are not stored in the
report server database. (rsInvalidDataSource-CredentialSetting)

Solution:

To store the credential, please do the following:
1. Open the Sqlserver Management Studio, connect to Reporting Services, go to the report you want to configure.

2. Expand the left panel, and click the Data Sources, right-click your data source name and click Properties.

3. Check the Credentials stored securely on the report server and specify a Login Name and password.

4. Click Ok and try to configure the report cache.

Testing Private Methods

Thu, 24 May 2007 04:09:23 GMT

Testing Private Methods with JUnit and SuiteRunner

Inserted from <http://www.artima.com/suiterunner/privateP.html>

Approaches given in this article are:

Approach 1: Don't Test Private Methods

As I mentioned in the introduction, I first heard the advice to suppress my occasional urges to test private methods from Daniel Steinberg. But Daniel is not only source of this advice that I have encountered. It seems to be a common attitude in the Java community. For example, the JUnit FAQ [4] states:

Testing private methods may be an indication that those methods should be moved into another class to promote reusability.

Charles Miller expressed a similar point of view in his weblog [5]:

If you have a thorough suite of tests for a class's exposed (non-private) interface, those tests should, by their nature, verify that any private method within the class also works. If this isn't the case, or if you have a private method so complex that it needs to be tested out of the context of its public callers, I would consider that a code-smell.

And Dave Thomas and Andy Hunt, in their book Pragmatic Unit Testing [6], write:

In general, you don't want to break any encapsulation for the sake of testing (or as Mom used to say, "don't expose your privates!"). Most of the time, you should be able to test a class by exercising its public methods. If there is significant functionality that is hidden behind private or protected access, that might be a warning sign that there's another class in there struggling to get out.

I believe all this advice. Most of the time, private methods can be most effectively tested via approach 1, indirectly by testing the package-level, protected, and public methods that call them. But inevitably, some people in some situations will feel that directly testing a private method is the right thing to do.

In my case, I tend to create many private utility methods. These utility methods often do nothing with instance data, they just operate on the passed parameters and return a result. I create such methods to make the calling method easier to understand. It is a way to manage the complexity of the implementation of the class. Now, if I extract the private method out of a method that already works and has good unit test coverage, then those existing unit tests will likely suffice. I needn't write more unit tests just for the private method. But if I want to write the private method before its calling method, and I want to write the unit tests before writing the private method, I'm back to wanting to directly test the private method. In the case of private utility methods, I don't feel my urge to directly test the methods is, as the JUnit FAQ put it, "an indication that those methods should be moved into another class to promote reusability." These methods are really only needed in the class in which they reside, and in fact are often only called by one other method.

Another reason I sometimes feel the urge to test private methods directly is that I tend to think of unit testing as helping me achieve a robust system by building that system out of robust parts. Each part is a "unit" for which I can write "unit tests." The unit tests help me ensure each unit is functioning correctly, which in turn helps me build a system that functions correctly as a whole. The primary unit I think in terms of when programming in Java is the class. I build systems out of classes, and unit tests give me confidence that my classes are robust. But to some extent I also feel the same way about the private methods out of which I compose package-access, protected, and public methods. These private methods are units that can be tested individually. Such unit tests give me confidence that the private methods are working correctly, which helps me build package-access, protected, and public methods that are robust.

Approach 2: Give the Methods Package Access

As I mentioned in the introduction, giving methods package access was my first approach to testing private methods with JUnit. This approach actually works just fine, but it does come with a slight cost. When I see a private access specifier on a method, it tells me something I like to know—that this is part of the implementation of the class. I know I can ignore the method if I am just trying to use the class from another class in the package. I could figure this out about a package-access method by looking more closely at the name, documentation, and code of the method, but the word private communicates this far more efficiently. Moreover, the main problem I have with this approach is philosophical. Although I don't mind "breaking encapsulation for the sake of testing," as Dave and Andy would put it, I just don't feel good about breaking encapsulation in a way that changes the package-level API. In other words, although I am quite enthusiastic to test non-public methods of classes, i.e., to create "white-box" unit tests, I'd rather the API of the classes under test, including the package-level API, not be changed to facilitate those tests.

Approach 3: Use a Nested Test Class

A third approach to testing private methods is to nest a static test class inside the production class being tested. Given that a nested class has access to the private members of its enclosing class, it would be able to invoke the private methods directly. The static class itself could be package access, allowing it to be loaded as part of the white box test.

The downside to this approach is that if you don't want the nested test class being accessible in your deployment JAR file, you have to do a bit of extra work to extract it. Also, some people may not like having test code mixed in the same file as production code, though others may prefer that approach.

Approach 4: Use Reflection

The fourth approach to testing private methods was suggested to me by Vladimir R. Bossicard, who wrote JUnit Addons [7]. One day over lunch, Vladimir enlightened me that the java.lang.reflect API included methods that allowed client code to circumvent access protection mechanism of the Java virtual machine. He also told me that his JUnit Addons project included a class, junitx.util.PrivateAccessor [8], to assist in using the reflection API for just this purpose: to write unit tests that manipulate private members of the classes under test. The JUnit FAQ points to a similar class, called PrivilegedAccessor [9], written by Charlie Hubbard and Prashant Dhotke.

One advantage of using the reflection approach to testing private methods is that it provides a clean separation of test code and production code. The tests need not be nested inside the class under test, as in approach 3. Rather, they can be placed alongside the other tests that exercise the package-level and public methods of the class. In addition, you need not alter the API of the class under test. Unlike approach 2, private methods can remain private. Unlike approach 3, you need not add any extra nested class at package access level. The main disadvantage of this approach is that the test code is far more verbose because it uses the reflection API. In addition, refactoring IDEs such as Eclipse and IntelliJ usually aren't as adept at changing the names of methods where they are referred to as Strings passed to the methods of the reflection API. So if you change the name of the private method with your refactoring IDE, you may still have to make some changes by hand in the test code.

Testing private methods (Bruce Eckel's blog)

Pasted from <http://onthethought.blogspot.com/2004/11/testing-private-methods.html>

Testing private methods (TestDriven JUnit Forums discussion)

Pasted from <http://www.testdriven.com/modules/newbb/viewtopic.php?viewmode=thread&order=ASC&topic_id=427&forum=7>

Unit Testing Stream zines

Fri, 18 May 2007 06:21:54 GMT

Unit Testing Stream zines

Please find the list of Streamzines for unit testing.

http://www.netobjectives.com/streamzines/TheCaseForUnitTesting/player.html

http://www.netobjectives.com/streamzines/NUnitFundamentals/player.html

http://www.netobjectives.com/streamzines/MockObjectsAndMockTurtles/player.html