Thread: Test Frameworks for Proprietary Software

I think as long as your software gets sales and has a steady income, it's probably good and stable enough to any buyer's eyes. No need to develop a hardcore test framework yet.

I wouldn't worry too much about how sellable the code is for now, just develop the software to suit the needs of it's users.

At the end of the day it's about kick ass software that sells like hotcakes, that's what business buyers would be looking for.

For me I personally haven't worried to much about testing yet.

My original plan was to market out the idea and offer beta signups etc, and when that was done start development. But however I managed to find a group of potential customers who are willing to help me grow my software before I start publicly selling it.

This lead to me developing a barebone version of my idea and they've been using it for a few months now. Just waiting til the end of the year to hear the results. Can't wait to hear what features I should add and what I should remove etc.

Best of luck!

David,

I don't meant to hijack your thread but what is your core programming competency? Are you a PHP guy? RoR? Python? Or a master at all?

Originally Posted by Bruce

I think as long as your software gets sales and has a steady income, it's probably good and stable enough to any buyer's eyes. No need to develop a hardcore test framework yet.

I wouldn't worry too much about how sellable the code is for now, just develop the software to suit the needs of it's users.

At the end of the day it's about kick ass software that sells like hotcakes, that's what business buyers would be looking for.

That's the thing that it really comes down to for me. Since I already know what my plan and strategy was going to be before I sat down at the table, I designed the system to be as extensible and readable as possible. Although my SDK's hit 9 different frameworks, each one of them is completely commented with their associated documentation format. There's only one class in each of them that's actually publicly visible haha, so the rest of the documentation and structure is there for future internal programmers.

While I was at Microsoft, I had to continually fight against unit test frameworks for a split between unit and integration. Although a unit test framework would have hit about 70% of the code, they wanted to use DI so they wanted to use DI on everything for mocks and fakes as well as have no private methods or variables to hit 90%. If you wanted to use a class A that completed it's task using classes B, C, and D, you had to pass in B, C, and D to the constructor of A, breaking half the rules for OOP haha.

Originally Posted by Bruce

For me I personally haven't worried to much about testing yet.

My original plan was to market out the idea and offer beta signups etc, and when that was done start development. But however I managed to find a group of potential customers who are willing to help me grow my software before I start publicly selling it.

This lead to me developing a barebone version of my idea and they've been using it for a few months now. Just waiting til the end of the year to hear the results. Can't wait to hear what features I should add and what I should remove etc.

That's good that you managed to find some buyers! I did as well, and they are anxiously awaiting the release. For the record, mine are service based customers. Is yours a product or service?

Best of luck, and I'd love to keep up on your progress!

Originally Posted by MJ DeMarco

David,

I don't meant to hijack your thread but what is your core programming competency? Are you a PHP guy? RoR? Python? Or a master at all?

Great question, I'm primarily a .NET C# developer, although I'm just as well versed in Java. I use NUnit for .NET and JUnit for Java test frameworks. I work well with any c-based language.

As for web, I went with PHP but wouldn't call myself a master at it just yet. Although I won't be setting up tests for the front end, the majority of the work is in backend services that would benefit from test validation.

As I know you have already built a big site with a robust backend and successfuly sold, how did you approach this?

Thanks MJ

Originally Posted by dknise

As I know you have already built a big site with a robust backend and successfuly sold, how did you approach this?

I would hardly call it "robust", in fact, it was a jumbled mess of spaghetti code. The bottomline was: It worked for the end users. The new company revamped the entire thing, which was something I recommended when I sold it.

Originally Posted by MJ DeMarco

I would hardly call it "robust", in fact, it was a jumbled mess of spaghetti code. The bottomline was: It worked for the end users. The new company revamped the entire thing, which was something I recommended when I sold it.

Oh wow haha, what was your language of choice back then? I'm sure you've talked about the project in more detail somewhere online before, do you have any links?

Someday I would love to buy you a beer or seven to pick your brain and chat!

Originally Posted by dknise

The tricky part is that I'm one of the few developers who is still hardcore against unit testing because of the severe design implications. While I have solid integration tests for each SDK and service, my unit tests often borderline as integration. Regardless, it tests the functionality of the code and will be well received by serious potential buyers.

How do unit tests have design implications? That article just has a sensationalist title with no substance.

Private methods don't need to be exclusively tested if they are hit through the public interface.

Originally Posted by Icy

How do unit tests have design implications? That article just has a sensationalist title with no substance.

Unit testing doesn't have design implications, designing code to get 90%+ code coverage in unit testing can.

And ya I didn't really write much. I'll be writing a much longer, more technical version with code examples soon. I'm not a fan of abusing DI for mocks and fakes and exposing code that should be hidden which is often what ends up happening. Rather than writing a "unit" test with mocks of every file IO object that gets used, just write an integration test. I've looked through test frameworks that faked everything in a method with a fake return value so the assertion at the end of the test was actually asserting if the fake test objects were written right, not the code hahaha.

Also... like I said at the bottom... for every person that's on my side of testing, there's ten on the other. If you're one of them, I'll understand.

Unit testing doesn't have design implications, designing code with getting 90%+ code coverage in unit testing can.

I agree with you here. There will always be situations that were misjudged (or simply hard to cleanly allow), and result in code that just isn't possible to unit test cleanly. Faking the tests to simply have coverage is a fools game.

I've looked through test frameworks that faked everything in a method with a fake return value so the assertion at the end of the test was actually asserting if the fake test objects were written write, and nothing about the code hahaha.

hahaha, geez.. I'm happy to have never have come across such code.

Also... like I said at the bottom... for every person that's on my side of testing, there's ten on the other. If you're one of them, I'll understand.

It's completely a game of cost\benefit for me. If something was 'interesting' to write, I'll write a few tests to have a bit of a sanity check, and in the case of a future bug, throw in a check for that (having a brain fart on the actual term..). I'm certainly no purist with it, but there are definitely benefits.

Originally Posted by dknise

oh wow haha, what was your language of choice back then?

.net / vb

Originally Posted by MJ DeMarco

I would hardly call it "robust", in fact, it was a jumbled mess of spaghetti code. The bottomline was: It worked for the end users. The new company revamped the entire thing, which was something I recommended when I sold it.

Hey MJ,

Did the fact that the code was a mess and they had to rewrite it affect the sale price at all? Would they have been willing to pay more if the code had been cleaner and more organized

Originally Posted by bernieshawn

Hey MJ,

Did the fact that the code was a mess and they had to rewrite it affect the sale price at all? Would they have been willing to pay more if the code had been cleaner and more organized

I'm interested in this as well. I've been designing my framework around the concept of selling it as a pre boxed network for the buyer, hoping that it will add to the value.