Search results matching tags 'altnetconf' and 'Agile'

ALT.NET Israel II - Done

Anonymous — Fri, 03 Apr 2009 12:44:00 GMT

It was fun doing ALT.NET in Israel again. For those of you who didn’t make it, Gadi has a very good play by play list of posts in hebrew (one, two, three, four, five, six, seven). Thanks to SELA for donating the classes, and thanks to Typemock for the food!

I am still fusing my thoughts about what I think the outcomes were. will blog when I have something of meaning to say.

ALT.NET Israel II happens TODAY

Anonymous — Thu, 02 Apr 2009 09:23:49 GMT

Just a quick reminder: ALT.NET Israel II is happening TODAY at 18:30 at SELA.

ALT.NET Israel – Meeting II 2d and 3rd of April

Anonymous — Tue, 17 Mar 2009 18:03:06 GMT

I’ll just repost this in Hebrew:

בשעה טובה ומוצלחת אני שמח לבשר על כנס alt.net israel השני
מיקום הכנס:
כמו בפעם שעברה, יתקיים הכנס בבית קבוצת סלע בבני ברק, ליד קניון אילון. תודה לאנשי קבוצת סלע על ההיענות לאירוח.
פרטים על סלע כאן: http://www.sela.co.il/, ומפת הגעה כאן: http://www.sela.co.il/?CategoryID=1295&ArticleID=642
מה בתוכנית?
יום חמישי 02/04 - יום התכנון
18:30-19:00 התכנסות, רישום וכיבוד קל
19:00-20:30 פגישת תכנון וקביעת הנושאים לדיון ליום הדיונים
20:30- ... המשך לא פורמלי באחד מבתי הקפה / פאבים באיזור

יום שישי 03/04 - יום הדיונים
09:00-09:30 התכנסות, רישום וכיבוד קל
09:30-09:40 שיחת פתיחה
09:40-10:50 סבב דיונים ראשון
11:00-12:10 סבב דיונים שני
12:20-13:30 סבב דיונים שלישי
13:30-14:00 ארוחת צהריים
14:10-15:20 סבב דיונים רביעי
15:20-16:30 סבב דיונים חמישי
16:30-17:00 פגישת סיכום
17:00- ... המשך לא פורמלי באחד מבתי הקפה / פאבים באיזור
יתכנו שינויים קלים בשעות הללו, עקב הגמישות של הפורמט. אנא עקבו אחרי רשימת הדיוור הזו ואחרי הבלוגים של המארגנים (רועי אושרוב, ליאור פרידמן וחן אגוזי) על מנת להישאר מעודכנים.
http://imistaken.blogspot.com/
http://weblogs.asp.net/rosherove/
http://www.kenegozi.com/blog
אזהרת מזג אויר:
מפגש התכנון בחמישי בערב יתקיים על גג הבנין. יתכן שיהיה קריר אז מומלץ לבוא בלבוש חם.
כמה מילים על הפורמט:
הכנס הזה לא דומה לכנסים אחרים שאתם מכירים.
לא מדובר בהרצאות פרונטליות, בהן מספר מצומצם של אנשים בא ללמד את המשתתפים, אלא בדיוני "שולחן עגול".
התכנים נקבעים על ידי המשתתפים (זה כולנו) ולא על ידי המארגנים בלבד.
לכן חשוב להגיע לפגישת התכנון - אז יקבעו תכני הדיונים ליום שישי.
מי שרוצה ללמוד עוד על הפורמט מוזמן להיכנס ללינקים שמופיעים בהמשך, ו/או לחפש על ALT.NET ו ALT.NET conf במנוע החיפוש החביב עליכם (גוגל, cuil, delver, live, yahoo ושאר החבורה)
תחומי עניין:
מטרת הכנס והקהילה בכלל היא לעורר שיתוף ידע והתדיינות פתוחה בין חברי הקבוצה.
על מנת לסייע בכך, נבקש מכל אחד מהמשתתפים לשלוח לקבוצה הזו (או אלי לדואל) את הפרטים הבאים:
1. שם המשתמש איתו אתם מזוהים ברשימת הדיוור הזו
2. שם אמיתי בעברית (או כינוי בו מכירים אתכם - כמו של Ayende Rahien למשל)
3. כלי פיתוח מעולם ה .net בו יש למשתתף מומחיות מיוחדת ו/או עניין מיוחד (על מנת לעזור ביצירת דיונים סביב נושאים אלו)
אנו נשתדל שיופקו מדבקות עם השם ותחומ/י העניין, שכל אחד ידביק על חולצתו במהלך הכנס
וכך המשתתפים יוכלו לפנות בשאלות האחד לשני במהלך ההפסקות, בזמן האוכל, בדרך לשירותים או בפקקים בדרך הביתה
עזרה:
למי שיש ויכול להביא מצלמות לתיעוד האירוע (גם סטילס אבל עדיף וידאו דיגיטלי) זה יהיה מצויין. המטרה היא להעלות וידאו של כל מפגש ומפגש לאתרי השיתוף השונים. גם מצלמת סטילס דיגיטלית שיודעת לצלם וידאו סביר על כרטיס הזיכרון באה בחשבון.
לינקים רלוונטיים:
http://altnetpedia.com/OverviewWhatIsIt.ashx
תיוג:
למי שכותב בלוג, מסמן לינקים בטקנורטי/דלישס/רדיט/דיגיט/אתר-הלינקים-של-מוישל'ה,
נבקש להשתמש בתג alt-net-israel על מנת שנוכל למצוא ברשת מידע alt.net-י בעברית בקלות

פרסום:
נהניתם? ספרו לחברים שלכם. לא נהניתם? חפשו ת'חברים שלכם. סתאאם. הקהילה מעצם טבעה פתוחה מאוד לביקורת בונה, וכולנו נשמח לשמוע הצעת לייעול / שיפור / שפצור ותחבור. (יש מילה כזו?)
ספרו לאנשים שאתם חושבים שזה מעניין אותם על קבוצת הדיוור הזו, ועל הקהילה בכלל. מגיע לכולם להנות, לא?
אז איפה נרשמים?
בימים הקרובים נפרסם קישור להרשמה. שמרו על עין פקוחה והירשמו בהקדם (עם פרסום הקישור) כי מספר המקומות מוגבל בסופו של דבר.

אז למי שמגיע לכנס - נתראה שם, ולמי שלא - נתראה בפעם הבאה.

Alt.Heros – Shanselman, benscheirman

Anonymous — Sun, 01 Mar 2009 23:38:55 GMT

In case you didn’t realize this, whoever Scott Hanselman’s manager is = you should give Scott a raise. He just made ALT.NET fun for people 6000 miles away using Kyte.com, a laptop and a buggy camera.

Thanks for being an ALT.HERO Scott. And thanks Ben, who was doing the same in parallel sessions.

That’s what I mean by “What are you going to do about it?”

Also, this is another great example of such thinking.

Two Faced Commits - how the ALT.NET Community is becoming more and more dogmatic

Anonymous — Mon, 19 May 2008 10:50:32 GMT

disclaimer: I work at Typemock.

There is a big trend I am starting to notice in the "Advanced" unit testing community. That trend feels more and more like hypocrisy. Take Daniel's post about mocking statics without Typemock. (Daniel is the creator of Moq, an open source mocking framework) Granted, it is important to know that you can always refactor things for testability, but just looks at what he writes:

"So, don't buy a product just because you're lazy and want to avoid creating a few wrapper classes and interfaces"

followed by

"Always use the simplest thing that could possibly work."

Which is it, community? The idea of being prgamatic is using the right tool for the job. if that tools makes your job easier than not using it "cause you're lazy otherwise" is plain old hypocrisy.

The same argument also holds for tools like FinalBuilder vs. Nant\MsBuild\Other XML Hell. Tools don't create problems if you use them correctly. The community (especially the ALT.NET community) is going in a too extreme direction. so extreme that their advice are sometimes skewed too much to be considered pragmatic, sometimes falling into "dogmatic".

View the forum thread.blog comments powered by Disqus

The evolution of Unit Testing Syntax and Semantics

Anonymous — Thu, 17 Jan 2008 11:21:59 GMT

The semantics of how you write a unit test, the basic syntax, or Domain Specific language of how we write them, has been relatively stale for quite some years now. But under the covers, the syntax revolution seems to be brewing, as people try to come up with newer, hopefully better and more readable syntaxes for tests and specifications that become more and more complex as the current Agile community struggles to accept best practices in this arena.

I'm guilty of that too, but a recent post by Jeremy Miller prompted me to try and list all the different syntax variations I've come across in the .net and some in java world (not necessarily in chronological order). Most ofthese didn't necessarily catch on as de facto standards, but are real world attempts to make a better world or explore new horizons.

POUT (Plain Old Unit Test) Syntax

JUnit initial syntax
Attributes: NUnit with attribute syntax, removing inheritance and test naming requirements
Extensibility: MbUnit is extensible testing framework with lots of powerful attributes.
Naming conventions for unit tests seem to be something people are actively looking for.
Simplicity is back: XUnit tries to go back to basics: No setup\teardown, different attribute names.
Fluent: My implementation of NRehersal uses delegates and a more fluent interface for tests

Mocking

Mocks Vs. Stubs: The Difference is explored (here too) and makes its way into some of the mock frameworks (NMock, JMock, Rhino.Mocks)
Explicit (reflection based) mocking statements such as (New DynamicMock(typeof(Interface), mock.Expect(...))
Record-replay syntax from Rhino.Mocks, EasyMock, TypeMock and others
fluent mocking APIs into our tests (NMock2)
Auto Mocking Containers (introduced by Elutian) will use RhinoMocks and Ioc Containers under the test covers (back to base classes)
Mocking the Un-Mockable: TypeMock (and JMockIt on the java side) introduce the possibility of mocking production code that is currently untestable without needing to refactor it.

BDD, Specifications and other Domain Specific Languages

Ruby SpecUnit, RBehave and RSpec make a dent in the .NET community and stuff start showing up in our world:
Extension Methods: Scott bellware comes up with the idea of using C# 3.0 extension methods for an easier expectation syntax.
NUnit.Behave, NBehave, NSpec , NSpecify try to use DSLs and fluent interfaces to express BDD specs.
Jeremy shows off his version of a more fluent and natural spec syntax by taking the auto mocking container idea, using structuremap under the covers and creating something that tries to be much more declarative and understandable at the same time. He uses delegates a lot as well.

I'm probably forgetting a few here, so let me know in the comments.

So, we see a nice evolution from beginner style to bdd and spec style. lots of work on the syntax is done, but there is currently lots of chaos. Think Blue-Day Vs. HD-DVD, only with about 5 main competitors. The nice thing about this: The community will decide what worls, so it would be interesting to see where we are one year or a two years from now in relation to this list!

Data Layer Testing: Test Inheritance Patterns

Anonymous — Thu, 29 Nov 2007 01:56:51 GMT

I'm preparing for my tutorial on Database and Data Layer unit testing that I will be giving at the Agile Practices Conference next week. It's always nice to have a full 3 hours to get pretty deep into something. 75 minutes just isn't enough to grasp a concept deeply enough, just to graze it around the edges.

When writing data layer tests, there are several patterns I've noticed, especially around the notion of inheritance within the test classes (Abstract test class pattern). I've observed at least three different patterns emerging from inheritance that I've personally used, all relating to data layer testing, but could be used elsewhere:

Abstract Utility Class

This class will usually be a base class for tests written for data layer objects. it would contain "facilities" such as database helper classes, setup and teardown methods that would automatically rollback any test and anything else a derived base class that was testing a data layer object would need (helper methods for asserting complex stuff, for example).

This is a classic "Abstract test class" pattern, and the next two are built on top of it.

Template Test Class

The template test class will contain abstract methods as unit tests, which any derived class would have to override and perform. That means that if you are always testing the same things against a data layer object (insert returns different IDs, update works etc...) test authors on new data layer classes who derive from this class will never forget to implement at least these basic tests.

they would also get the facilities for doing assertions and other things from the base class, as depicted in the previous pattern. makes sure you don't forget tests, saves some time on the infrastructure.

Abstract Driver Test Class

This class will have non abstract test case methods inside it that will always run the same way. these test methods will call (using abstract methods) to the derived class' implementation of type specific actions (insert specific for a category, or update specific to person) .

That leaves the derived class to only implement very basic things such as insert (and return the ID), update, or delete (by ID). the test methods in the base class will do the rest of the work. derived classes don't need to implement any tests unless they want to add type specific tests which don't belong on the base class.

in the image to the left the green methods are tests that the base class runs, and the yellow ones are type specific helpers that the derived class has to implement.

this makes writing tests for a new data layer object (as long as its interface is the same) very simple by inheriting a test class and implementing a few methods. all the test permutations in the base class will then run on the data layer object. saves lots of time and forgetting tests.

What patterns have you come across?

Mocking LINQ Queries, Extension methods and Anonymous Types

Anonymous — Sat, 17 Nov 2007 21:47:14 GMT

One of the things I wanted to show at my Interactive session on unit testing tips and tricks at TechEd this year was how you can "Stub" out results from LINQ Queries, or mock\stub Extension methods in .NET 3.5 (what's the difference between mocks and stubs?)

The only mocking framework in existence that can truly stub out LINQ queries and extension methods is TypeMock.NET.  Another option, if you use LINQ to SQL, is to be able to mock out the DataContext and the IOrderedQueriable interface, as outlined here, to return a custom query result set.  I'll talk about the first option in this post, since it is much easier to read and understand. I may touch on the second one in a later post.

TypeMock, I've talked about it before, is a very powerful mocking framework. much more so than Rhino Mocks or NMock, because it allows isolating static methods, private methods, constructors, and basically anything you can do in IL, because it uses the .NET Profiler APIs to intercept method calls and do whatever it wants with them.  In that regard, it is almost too powerful because it rids of of the need to actually design your code for testability, and just test it as is (how you actually write the tests is another matter for another post).

But I'd rather have the argument whether TypeMock is good or bad, than not have TypeMock on the scene at all, simply because it's just too damn valuable as is (disclosure: TypeMock is owned by a friend of mine).

It's the only real framework that can deal with real untestable legacy code and still allow you to isolate classes enough to test them without changing the code under test itself.

It's the only framework that allows to write unit tests for code that is based on .NET 3.5 and uses LINQ Queries and extension methods, allowing to isolate these two types of code and thus be able to separate things from their dependencies.

Here are some examples I wanted to show (takes fro the examples that come with the TypeMock download:

Example: Stubbing out LINQ Query Results

First, we're going to create one fake result to return (array) from the LINQ query, and also introduce the real data source from qhich to query (realCustomerList). note that the customer list has 3 entries, and the fake list has only two entries.

 ///Two Customer instances used as fake values

 private static Customer fakeCustomer1 = new Customer { Id = 0, Name = "Fake1", City = "SF" };

 private static Customer fakeCustomer2 = new Customer { Id = 1, Name = "Fake2", City = "Redmond" }; /// A fake list used as return value in the tests private List<Customer> fakeCustomers = new List<Customer> {fakeCustomer1,fakeCustomer2 }; /// A list containing 3 cusotmer use as the "real data" private List<Customer> realCustomerList = new List<Customer> { new Customer{ Id = 1, Name="Dave", City="Sarasota" }, new Customer{ Id = 2, Name="John", City="Tampa" }, new Customer{ Id = 3, Name="Abe", City="Miami" } };

Here's how the unit test looks:

 1: [TestMethod]

 2:  public void MockSimpleQuery()

 3:  {

 4:  using (RecordExpectations r = new RecordExpectations())

 5:  {

 6:  var answer = from c in realCustomerList select c;

 7:  r.Return(fakeCustomers);

 8:  }

 9: &#xA0;

 10:  var actual = from c in realCustomerList select c;

11:

 12:  Assert.AreEqual(2, actual.Count<Customer>());

 13:  Assert.IsTrue(actual.Contains(fakeCustomer1));

 14:  Assert.IsTrue(actual.Contains(fakeCustomer2));

 15:  }

.csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

Line 6 is the one that tells the TypeMock record what LINQ query to intercept.

Line 7 tells TypeMock what value to return when this query is intercepted. that means the query will never really take place.

finally, we assert that what we got from the query is the fake list of customers. Pretty darn easy.

But is this a good test? Not really. this is only a demo of what you code intercept with typeMock. a real unit test will actually test a piece of code that runs this query, and, instead of providing it with a list of objects to query, will just provide it with the fake return value to receive

Example: Test that an anonymous type is created correctly

 1:  [TestMethod]

 2:  [VerifyMocks]

 3:  public void MockAnonymousTypeTest()

 4:  {

 5:  using (RecordExpectations rec = new RecordExpectations())

 6:  {

 7:  //Mock the creation of the Anonymous Type

 8:  var p1 = new { Name = "A", Price = 3 };

 9:  rec.CheckArguments();

 10: &#xA0;

 11:  //fake the value of the Name Property

 12:  rec.ExpectAndReturn(p1.Name, "John");

 13:  }

 14:  //if creation will be done diffrently an exception will be thrown.

 15:  var target = new { Name = "B", Price = 3 };

 16:  //verify that the fake value is returned

 17:  Assert.AreEqual("John", target.Name);

 18:  }

Line 8 tells the typemock recorder that this is the anonymous type creation we'd like to intercept.

Line 9 tell it to assert internally that the anonymous type is indeed created with the correct "Name" property value and the correct "Price" property value. so if I later initialize the anonymous type with the wrong values, I will get a test exception based on the expected values. Pretty neat.

Line 12 is just an example of how you can also intercept and retun whatever value you'd like from the property of an anonymous type. in this case the name will always return "John" even though it may have been initialized differently.

Example: Mocking Extension Methods

Extension methods are static methods, which means you can't replace them with a different method instance. there are ways to design yoru code so that the calls to the static methods are testable, but assuming you're testing code that cannot be changed, or that is hard to redesign, intercepting the method call itself is almost the only choice.

assume you've extended the Point class by adding this extension method:

 public static class Extend { public static Point Multiply(this Point extendedInstance, int scalar) { extendedInstance.X *= scalar; extendedInstance.Y *= scalar; return extendedInstance; } }

&#xA0;

Now you could write a test like this:

 1:  [TestMethod]

 2:  [VerifyMocks]

 3:  public void MockExtensionMethod()

 4:  {

 5:  using (RecordExpectations rec = new RecordExpectations())

 6:  {

 7:  Point mocked = new Point(7, 9);

 8:  mocked.Multiply(6);

 9:  rec.Return(new Point(5, 5));

 10:  }

 11: &#xA0;

 12:  Point target = new Point(7, 9);

 13:  Point actual = target.Multiply(6);

 14: &#xA0;

 15:  //Verify the returned vcalues

 16:  Assert.AreEqual(5, actual.X);

 17:  Assert.AreEqual(5, actual.Y);

 18:  }

in line 7 we're actually using the extension method as part of our recorder, and telling the record to return a specific value. then we later use that value in our code under test (like 13) and assert that we god the mocked value instead of the real one (the extension method is not executed).

What about other technologies?

could you use this to test code that relies on other non testable technologies, like windows workflow, WCF etc? the answer is a big yes. the same principles apply, and most of these frameworks were not built with testability in mind.

it's in those cases where people ask "how can I test such code where everything is sealed, private and static?" that I tell them that, currently, TypeMock is the only framework that solves this problem at a satisfactory result.

Organization Problems - Sounds Familiar?

Anonymous — Thu, 18 Oct 2007 13:08:03 GMT

I just finished a summary of a company's review about work modes and problems before we can start doing something about it. I'm posting part of it as anonymous because I think this seems to relate to many other companies out there:

"The QA Department seems to be the main gripe of most of the departments in the company. The main issues are of it being staffed with personnel who does not really understand the application aspects of what they are testing, and so don’t really know what to test in the application. Another main issue is the lack of knowledge about proper QA methods. Each QA department seems to be reinventing the wheel and creating its own methods. This also leads to the face that most tests are not automated and most tests don’t even get repeated for regressions after each release, which leads to an overall lower quality in the product.
...
The Marketing division seems to be a large source of problems. Most of these come from the fact that Marketing people also serve as Product Managers in the company (Those who should be truly representing the client’s real needs), setting feature priorities and agenda for the next release with ultimate decision power. Because there is a conflict of interest between the role of marketing and role of Product manager, many of the things that are requested from other departments such as Customer Support are considered haphazardly if at all, which leads to a product that contains features a real customer might not need, but misses features the customer really does need. Add in a true product manager role into the company can help alleviate many of these issues as well as the partial amount of time that marketing has of actually communicating with all relevant departments as a customer.
...
The X group is highly motivated in implementing agile practices such as unit testing, and are suffering from lack of automation in the group, “islands” of knowledge and lack of code reviews.
...
Management has a big role in creating the current conditions for problems. The lack of CTO, and the fact that the CEO is the one who is “acting CEO” lead to lack of real technical leadership (lack of time to handle things) and no clear “head” to turn to and get quick good answers. Management can help by supporting practices such as unit testing and automation and getting and hiring good people into the missing roles in the company (Product managers, CTO) and by allowing for real time extensions to projects that would like to implement them.

...

Generally speaking, there are various “pain points” that currently prohibit the departments from either getting the full data they need, influence the current releases so they contain the correct feature set or be more productive in their work. A main example is the big confusion about the various issue management software: which is reported to be almost unusable and there is no clear sync between that and X and Y issue management software also used in the other departments. Also the fact that developers aren’t really aware of what the application is used for in the field leads to believe that more time spent with the customer can help. Overall many “small” things can make for a large difference in the organization’s ability to create quality software and get better communication between the departments more quickly.
"

Database and data layer testing techniques at ALT.NET - slides and code

Anonymous — Wed, 10 Oct 2007 10:39:36 GMT

I contributed some material to the session about Database and data layer testing techniques at ALT.NET.

The slides and code I used at ALT.NET are the same ones I used at DevTeach, so you can download them here.